标签: 架构

  • 顶尖咨询顾问经验分享:企业业务架构能力地图、端到端业务流程、业务架构视图构建

    顶尖咨询顾问经验分享:企业业务架构能力地图、端到端业务流程、业务架构视图构建

    企业业务架构规划系列:

    上集连接:01企业业务架构规划核心思路、流程架构、价值链及业务能力地图构建

    03

    价值链分析 | 流程分析

    ✦



            3.1 制造业价值链

           制造业的价值链是由商业模式推导出来,制造业的业务模式属于稳态业务,所以顶层价值链是比较容易推导出来的,根据企业的实际业务运作和管控模式情况进行调整。价值链一般分为战略层、运营/核心层、支撑层。

           

            3.2 流程分析

           企业价值链梳理完成后,需要根据企业实际情况对业务域进行流程的梳理。流程分析主要涉及两种流程,职能流程和端到端流程。

           职能流程一般企业都有梳理,在实际数字化规划中,职能流程主要用来帮助我们快速识别企业的业务组织和职能划分,帮助后续识别业务能力和组件。

           端到端流程在数字化规划中,需要我们根据根据业务主线进行梳理,从业务域跨部门角度,对业务流和信息流进行梳理,识别企业中存在的业务和信息的断点和痛点,为后续的业务和应用架构规划提供支撑。



           端到端流程和职能流程的关系如下图所示,端到端流程是由多个职能流程组成的。端到端流程的目标是围绕以客户为中心的角度,打通内部的部门墙,提升业务组织效能。        


           

            3.3 职能流程分析

           以职能角度的流程分析,可以帮我们快速识别企业核心业务,为后续的业务能力识别和业务组件规划提供帮助。下图为企业的职能流程地图。



            下图是根据某制造企业企业职能流程梳理的职能能力地图。



           3.4 端到端流程分析

          端到端流程是企业以客户为中心,推进企业数字化转型和企业变革的核心工作,大的推行可能会涉及到企业组织结构和业务模式的变革。对于数字化规划来说,主要是对企业核心业务,通过端到端的流程,对业务和信息流进行识别和梳理,提升跨组织跨部门间的业务协作能力,提升组织效能。下图是制造业端到端流程的框架图。



            在做端到端流程时,可以参考华为的几大流程。



          数字化规划过程中,端到端流程梳理和表现方式有很多种,其中重要的是识别端到端业务交互过程中,企业的业务流和信息流存在的断点,识别业务痛点。

          制造业涉及的端到端流程梳理项目包括:从采购到付款、从研发到生产、从生产到成本、从销售到回款、从需求到供应。

          下图为从制造业从销售到回款端到端价值链流程梳理。

           下图是从系统端进行端到端业务的梳理。


           3.5 基于流程视角的业务架构图

           业务流程建模分析完成后,企业会得到基于流程视角的业务架构图。下图案例是一家制造业的示例图。对于流程要做多深,一般要看咨询项目的要求。 


          数字化的咨询主要是进行端到端的流程梳理和分析,识别业务流和信息流的断点和痛点。其次是通过业务流程识别业务对象,为后续的业务能力分析和业务组件识别、合并提供支撑。顶层规划项目对于企业业务流程的梳理一般是梳理到L3级。下图为制造业寻源到付款L1-L3级流程。



    (未完待续…)

    相关学习参考:

    41页PPT | 华为流程架构全景:全业务域L1-L3级流程规划视图
    52页PPT | IBM业务架构咨询:制造业业务流程L1-L4级框架规划精要
    350页PPT | IBM咨询:制造业ERP信息化4A架构业务视图设计全案
    400页PPT | 麦肯锡企业架构全套方案(业务、数据、应用、技术、治理架构)
    186页PPT | 变革浪潮:华为MPR+LTC流程,引领销售新革命!

  • 公司组织架构设计(经典通用版本)

    公司组织架构设计(经典通用版本)

    本文的两个重点问题:
    1,公司组织架构为什么需要设计?
    2,什么组织架构才是经典的版本?


     公司组织架构为什么需要好好设计?
    我在前段时间给客户做公司架构图的时候,我才知道原来这件事其实很多公司都没有做好,我甚至发现,能把组织架构梳理清楚的公司,原来那么少,大部分公司的组织架构都很混乱,五花八门。
    就是说,很多公司的某些部门,你光听名字,你是无法知道那个部门到底是干嘛的?
    比如,很多公司都有一个部门,叫事业部,一听就懵了,事业部到底是干嘛的呢?没人知道,里面也是乱七八糟,什么都有。谁干工作不是为了公司事业?什么工作不可以归在事业部呢?
    所以,这种部门的划分,其实就是无效的,混乱的。

    比如,很多公司也有一个部门叫市场部,啥叫市场呢?这也是让人很困惑的,表面上好像谁都知道什么叫市场,但仔细一想,好像又不是很明朗。是不是有这种感觉?

    所以组织架构的混乱,容易让公司人力部门在人员安排上出现混乱,严重的甚至会因为分工不明确而导致工作的重复冗余,导致有些员工,在自己工作需要做什么自己也是懵逼的。

    就像销售,销售理论上肯定是市场部的,但还有一类人,就是对外宣传和搞推广活动的人员,理论上也应该是市场部的!问题是他们在工作上可完全是两回事,不同的两类工种。部门领导,相当于在管两个部门的事情,那能不乱?

    当然,还有什么设计部,设计它能叫一个部门吗?完全就是乱来。
    为什么我这版架构才是经典通用版本? 
    就是因为我这个版本的架构图,几乎适用于任何行业,也是最美最简洁的架构图,不重不漏,当然就可以是最经典的通用版本。
    随便举一个行业:比如设计公司,有人说,你不是说设计部不能成为一个部门吗?设计公司的设计就是一个部门?那不一定,设计公司怎么去架构呢?依然是逃不过我的经典版。
    比如产品部,对设计公司来说,什么是公司的产品?设计作品,当然,对设计公司来说,是应该把产品部改为设计部的,但本质上,设计作品就是公司产品。你的产品决定了客户是不是满意,是不是愿意再次购买。
    所以作品的设计师和推广宣传的设计师,做的事情看似是一样的都是设计,但功能是不一样的。
    而设计公司的渠道部,其实就是所谓的AE部门,就是客户部门,也就是你从哪里获取客户的这个部门。
    而推广就不难理解了,就是在不同渠道上去推广宣传本设计公司的这个部门(员工的工作重心和任务)。
    你看,逻辑是不是一样的。
    再比如,财务公司,产品就是给公司做的财务质量,是不是解决了公司的问题,解决得好,就是产品做得好。
    再比如,搞工程的公司,什么建筑啊,路桥之类的,这种公司的产品,就是他们修的房子,修的路,修的桥。
    另外的渠道和推广,可能不那么需要,其实也是存在的,只是比重不大而已,但内在的逻辑和设计公司的例子是一样的。
    如果是有实物产品的公司,比如快消品,那就更不用说了,就更加容易理解了。
    所以,任何公司只要在这个经典架构的基础上,根据公司具体情况,稍做修改,就能为公司创造一个合理而简单的组织架构。
    希望这个组织架构图,给需要开公司的朋友有帮助,让你们的公司在架构上,不重不漏,每个人的工作都很清晰,从而让公司的运转更加简单高效。


    如果喜欢本文或有想说的话

    直接点“在看”分享,或者“留言评论”就好

    本文编辑排版:Sandy 


    如有品牌方面的问题需要帮助,欢迎联系

    17132300246

    936351637@qq.com

    或

    直接“后台”留言

    或

    长按下图👇🏻识别二维码+微信好友


    #公司经典组织架构图丨管理篇

  • 全球首个多模态天工AI3.0:基于MoE架构的大模型发展与创新

    全球首个多模态天工AI3.0:基于MoE架构的大模型发展与创新

    点击蓝字 关注我们


    01

    MoE的发展历程


    混合专家模型(MoE)的发展历程可以追溯到1991年,当时由两位人工智能领域的泰斗Michael Jordan和Geoffrey Hinton首次提出了这一概念;他们发表的论文《Adaptive Mixtures of Local Experts》为MoE技术奠定了基础;这一技术的核心思想是通过将复杂任务分解给多个专家网络来处理,从而提高整体模型的效率和性能。

    尽管MoE的概念早在上世纪90年代就已提出,但其在实际应用中的推广却相对缓慢,直到近些年才迎来了重要的突破;2020年,Google在其论文《GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding》中首次将MoE技术引入到Transformer架构中;这一创新使得MoE技术在大模型领域的应用成为可能,推动了“MoE+大模型”时代的到来。

    2022年,Google再度突破,在其论文《Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity》中提出了Switch Transformers模型;这一模型的参数规模达1.57万亿,与此前T5模型相比,在相同的计算资源下实现了高达7倍的预训练速度提升,并实现4倍的模型加速,成功突破了万亿参数大关;这一突破不仅验证了MoE技术的可行性,也展示了其在大规模模型训练中的巨大潜力。

    在国际上,OpenAI,X,Mistral AI等公司纷纷推出了基于MoE架构的大模型,如GPT-4,Grok-1和Mistral等。


    混合专家模型(MoE)在国内的发展

    // 天工AI大模型的崛起

    昆仑万维集团是国内MoE大模型发展的重要推动者;2023年4月17日,昆仑万维发布自研双千亿级大语言模型「天工1.0」,正式奠定了国产大模型崛起之路。2024年4月17日,昆仑万维重磅宣布,「天工3.0」正式开启公测。

    // 天工3.0的创新和性能提升

    「天工3.0」采用4000亿级参数MoE混合专家模型,是全球模型参数最大,性能最强的MoE模型之一;相较于上一代「天工2.0」MoE大模型,「天工3.0」在模型语义理解,逻辑推理,以及通用性,泛化性,不确定性知识,学习能力等领域拥有惊人的性能提升,其模型技术知识能力提升超过20%,数学/推理/代码/文创能力提升超过30%。

    天工3.0还新增了搜索增强,研究模式,调用代码及绘制图表,多次调用联网搜索等能力,并针对性地训练了模型的Agent能力,使得天工3.0能够独立完成规划,调用,组合外部工具及信息,以精准高效地完成产业分析,产品对比等各类复杂需求,带来全新的颠覆式人工智能体验。

    // 天工AI的多模态能力

    「天工3.0」是全球首个多模态“超级模型”(Super Model),集成了多项尖端AI技术和功能,其中天工AI搜索在天工AI中占据核心地位。

    天工ai地址:https://www.tiangong.cn/

    天工AI搜索是中国第一款AI搜索产品,也是我使用最多的国内AI搜索,在项目开发过程中,有什么问题或知识点不清楚都是用它来搜索;在使用过程中,深刻体会到它的不可替代和强大功能,比如:

    • 增强搜索:处理复杂查询,精准理解用户意图。

    • 实时联网搜索:获取最新信息,确保数据时效性和准确性。

    • 研究模式:深入分析复杂问题,提供结构化或思维导图形式的展示。

    • 多次调用联网搜索:多次获取信息,确保全面准确的结果。

    • 多模态信息处理:能够同时处理文字和图像数据,例如,在搜索增强功能中,天工AI能够理解复杂的查询,精准地处理搜索结果的图像和文本内容(如上图所示),为用户提供准确和多样化的搜索结果;天工AI是中国AI产品里唯一具备这种图文并茂的搜索结果展现形式的,堪称孤品。

    天工AI通过集成天工AI搜索的强大功能,以及AI写作,AI对话,AI语音合成,AI图片生成等多模态能力,成为全能的AI助手,展现了卓越的实力和广阔前景。


    02

    混合专家模型(MoE)的优势


    提高模型容量和性能

    MoE模型相比传统的稠密模型,能够在远少于后者所需的计算资源下进行有效的预训练,计算效率更高、速度更快,从而使得模型规模得到显著扩大,获得更好的AI性能。

    提升推理计算效率

    MoE在模型推理过程中能够根据输入数据的不同,动态地选择不同的专家网络进行计算;这种稀疏激活的特性使得MoE模型拥有更高的推理计算效率,进而提供更快的AI响应速度。

    强化处理复杂任务的能力

    由于MoE架构中集成了多个专家模型,每个专家模型都能针对不同的数据分布和构建模式进行优化,从而显著提升大模型在各个细分领域的专业能力,使得MoE在处理复杂任务时表现更好。

    灵活性和可扩展性

    针对不同的专家模型,AI研究人员能够采用特定的优化策略,并通过增加专家模型数量,调整专家模型的权重配比等方式,构建更为灵活,多样,可扩展的大模型。



    03

    什么是混合专家模型(MoE)


    MoE的核心逻辑

    混合专家模型(MoE,全称Mixture of Experts)是一种创新的大模型架构,其核心思想是“术业有专攻”,将复杂任务分解并分配给多个专家网络来解决;MoE与传统的稠密模型(Dense Model)相比,更能有效处理复杂任务,提高计算效率和模型性能。

    在MoE架构中,每个专家网络专注于解决特定类型的问题,而门控网络(Gating Network)负责将输入数据分配给合适的专家网络。这种设计让MoE模型在不显著增加计算成本的情况下,大幅提高了模型的容量和性能,使得万亿参数级别的大模型成为可能。

    MoE的技术原理

    混合专家模型(MoE)的核心工作原理是通过门控网络(Gating Network)将输入数据分配给多个专家模型(Experts),每个专家模型专注于处理特定类型的数据,从而提高整体模型的效率和性能。以下是MoE模型的具体工作流程:

    • 数据分块:输入数据被分割成多个区块(Token)。

    • 门控网络分配:每组数据首先进入门控网络,门控网络根据数据的特性将其分配给一个或多个专家模型;门控网络负责决定每个数据块应由哪个或哪些专家来处理,这种动态分配机制确保了数据能够被最合适的专家处理。

    • 专家处理:每个专家模型专注于处理分配到的特定数据部分;每个专家模型都是一个小规模的神经网络,专门针对某一类任务进行优化;通过这种方式,专家模型能够以更高的效率和准确度处理数据。

    • 结果汇总:所有专家的输出结果被加权融合,形成最终输出;在这一步骤中,模型将各个专家的处理结果进行整合,以提供一个综合的解决方案。

    传统大模型(左)和MoE大模型(右)的对比展示了在数据流转过程中,MoE架构集成了一个专家网络层(红框部分),提高了模型的处理效率。

    专家网络层由门控网络和多个专家模型构成。数据首先进入门控网络,由门控网络将数据分配给一个或多个专家模型;专家模型处理后,结果被加权融合,得到最终输出。

    这种架构通过稀疏激活(Sparse Activation)的特性,实现了在不显著增加计算成本的情况下,提高模型容量和性能;具体来说,稀疏激活意味着在每次计算中只有一部分专家模型被激活,从而大幅减少了计算资源的消耗;这使得MoE模型能够在处理复杂任务时表现出色,同时显著提升训练和推理的效率。


    04

    总结


    天工AI搜索作为中国第一款AI搜索产品,以其卓越的性能和多样化的应用场景,展示了AI技术的无限潜力和广阔前景。

    天工AI将MoE架构赋能到AI PPT,AI视频转绘,AI音乐生成,AI写作,AI长文本阅读,AI对话,AI语音合成,AI图片生成,AI漫画创作,AI图片识别,AI代码写作,AI表格生成等多项核心产品能力中,展现多模态的极致能力。

    混合专家模型(MoE)凭借其术业有专攻的设计理念,通过将复杂任务分解给不同的专家网络来处理,显著提升了模型的整体性能和效率;在全球范围内,MoE大模型的研究和应用正在快速推进,昆仑万维的天工系列大模型正是这一领域的重要代表;天工3.0以其强大的技术创新和多模态能力,不仅推动了国内大模型的发展,更在全球范围内树立了标杆。


    亲爱的读者们,如果这篇文章让你有所收获,或者仅仅是让你的嘴角上扬,那就不要吝啬你的手指,轻轻一点,给予我们一个小小的赞👍。你的每一次点赞,都是对我们最大的鼓励和支持!

    而且,别忘了点击“在看”,让你的朋友们也能享受到这份知识和乐趣。毕竟,好东西要分享,不是吗?😉

    我们下期再见,期待你的持续关注和互动!👋



    🎉往期文章 🎉

    可控人物视频生成大模型vimi腾空出世,1张照片玩转3种控制,打造60秒高燃视频(含申请链接)

    快手可灵再添盟友:寻光AI视频创作平台,让创作变得更简单(含申请链接)

    全网最全的16款免费AI数字人视频工具(部分含整合包)

    文本转高质量语音在线免费工具TextToSpeech:打破语言障碍,51国语言和8000多种音色任你选

    【不花一分钱】重温旧时光,人人都会的老照片动起来制作全攻略!

    全网首创:10分钟教你打造一个全能型反推生图AI工具,小白也可以上手!(含完整的实战步骤)

  • 业务架构全景视图该怎么画?

    业务架构全景视图该怎么画?


    内容摘要

    • 业务架构全景视图是快速理解业务运作形态的重要工具,该视图不应以IT视角绘制,业务元素及其结构应是绘制重点
    • 商业模式画布中业对务元素进行了标准化,将其业务活动展开可得到一份精炼的业务全景视图,两者可互为补充
    • 由于篇幅限制和认知曲线,应该控制全景视图的知识颗粒度,将其作为探索业务实现细节的地图


    业务架构全景视图不长什么样?

    都说技术是为业务服务的,我们首先要搞清楚业务本身是如何开展的,这样才能有的放矢地为其构建技术解决方案。但大多数IT从业人员并非业务出身,我们如何才能快速理解业务呢?
    企业架构是研究这一课题的学科,主流企业架构框架一般认为企业架构分为两大部分:业务架构和 IT 架构。业务战略决定了业务架构,业务架构会描述其业务运作模式及其他业务元素间的结构关系,例如流程体系、组织结构、地域分布等。也就是说,想理解业务如何开展,业务架构应该是我们可依靠的工具。
    当我们在研究架构时,相比于文字,视图往往是更流行、更有效的表达形式。例如,我们可以使用流程视图来描述业务流程体系。但流程是业务架构的“实现细节”,我们希望有一张全景视图,可以抽象地描绘业务的运作模式,作为其他“实现细节”视图的分析起点。但令人失望的是,当你搜索业务架构相关的图片时,很少能找到符合业务架构定义的结果,搜索结果常常展示的仍然是各种系统(功能)的组合结构。

    网上找到的某个电商业务架构全景视图,此类风格的业务架构全景图比比皆是

    首先,业务架构全景视图应该能让业务人员看懂,这样我们才能和他们讨论得有来有回。其次,该视图也不应是IT系统的功能罗列,否则视图就陷入细节,变成了密密麻麻的方块堆积。因此,业务架构视图绝不应该以IT视角来绘制,以免产出”既不业务,也不架构“。

    商业模式画布或许是一个不错的参考

    在主流企业架构框架里,商业模式画布是常见的顶层分析框架之一。其从客户群体、客户关系、渠道通道、价值主张、关键业务、核心资源、合作伙伴、成本结构、收入来源这九个关键词描述了企业(产品)如何创造价值、传递价值、获取价值的基本原理。

    商业模式画布示例

    简单说下商业画布的九宫格:

    1、客户细分(Customer Segments):我们为谁提供服务?为谁创造价值?谁是我们的重要客户?

    任何一个企业或组织都会服务于一个或多个客户群体,但没有一个产品或服务可以满足全部人群的需求,产品规划中应明确到底该服务哪些细分的客户群/用户群。

    2、价值主张(Value Propositions):我们为客户提供什么样的产品或服务?一个企业的价值主张在于解决客户的问题和满足客户的需求。

    3、渠道通路(Channels):我们用什么样的渠道将价值主张(商品)传达(卖)给客户?渠道通路就是将企业的价值主张通过沟通、分发以及销售渠道传递给客户。

    4、客户关系(Customer Relationships):如何与客户建立联系,维护客户关系(让他再买)?客户关系以客户群体位单位建立和维护。

    5、收入来源(Revenue Streams):将价值主张成功提供给客户,从每个客户群体中获取现金收入。

    6、核心资源(Key Resources):为实现以上各项元素的供给和交付,我们所拥有的核心的有竞争优势的资源是什么?

    7、关键业务(Key Activities):为了达成商业模式,实现供给和交付,我们要做的关键业务是什么?

    8、重要合作(Key Partnerships):让商业模式有效运行所需要的重要供应商和合作伙伴是谁?

    好的商业模式需要好的联盟,帮助我们获得资源降低风险。

    9、成本结构(Cost Structure):商业模式有效运行所需的所有成本是什么?成本结构取决于经济模式中的各项元素。

    虽然只有一页纸,但其将业务模式中的元素进行了标准化,并强调了各元素间如何相互作用。这是脱离IT视角的表达方式,而且高度抽象,是快速理解业务的优质输入。略有些遗憾的是,其关键业务(活动)部分篇幅有限,对于理解业务活动如何开展,有些过于精炼。因此,可以将商业模式画布中的部分元素展开,形成如下布局:

    业务架构全景图模板
    • 半环绕式布局,以”运行“为中心,运行部分描述业务日常运作的关键活动,形成一个粗粒度的价值流

    • 左侧罗列资源开发活动和合作伙伴的能力,这是业务日常运作的基础

    • 右侧罗列业务的渠道通路,业务日常运作产生的价值由此传递给客户

    • 上方是业务策略规划和管控活动

    相比商业模式画布,由于这个视图展开了关键业务活动,对下一步定义IT架构来说更友好一些。在实际的业务架构定义过程中,商业模式画布与该全景视图并非是二选一的关系,而是可以相互补充。

    接下来通过两个例子来演示该视图的效果:

    示例-1,电商业务架构。根据之前IT视角的”业务架构视图“反推,得到新的全景视图如下,相较上一个版本,去除了IT视角的”噪音“。

    示例-1: 电商业务架构全景视图

    示例-2,采购招投标业务架构。该模板可同样为非交易类业务服务,如采购领域的招投标业务全景视图如下:

    对于没有该领域知识的人士来说,如果你能依据该视图,对其业务运作模式有一个快速理解,我们的目的就达到了。

    从业务架构全景图下钻展开业务实现细节

    由于篇幅限制和认知曲线,全景视图应该只展示粗粒度的元素及其结构,作为一份探究业务实现细节的地图。接下来,可以按需要打开某个业务活动,以业务流程视图等成熟工具来展现。

    如果说业务架构衔接了企业战略与IT架构,那么希望这份业务架构全景图可以在业务架构中扮演承上启下的作用,衔接业务战略与业务实现细节。

    PS:加入数据学堂知识星球,搜索“业务架构”,获取更多干货资料



    <END>


    大家都在看:
    1、大数据能力平台建设方案(PPT)
    2、数据分类分级方法、标准及应用实践
    3、华为数字化转型:从战略到执行(PPT)
    4、数据治理咨询项目:《XX集团数据管理办法》.doc
    5、数据治理体系架构设计方案(PPT)
    6、华为 VS 阿里数据中台建设方法论
    7

    、

    一文读懂DAMA数据治理工程师认证考试

    8、终于有人把数据指标体系讲明白了
    9、数据安全治理体系建设思路和方法
    10、数据资产目录建设方案
    11、非结构化数据治理方案
    12、德勤:集团主数据管理方法论(PPT)
    13、企业大数据平台顶层规划设计方案(PPT)
    14、终于有人把数据中台讲明白了
    15、企业数字化转型之道(PPT)


    数据学堂


    欢迎扫码添加歪老师个人微信(data-school),邀请加入数据学堂数据治理专业微信群,与业内大咖一起识数据、存数据、管数据、治数据、用数据!

  • B端系统-商业模式架构

    与C端的产品不同,B端的商业模式大不一样,毕竟很难在产品中直接插入广告进行变现。这篇文章,我们和作者一起了解下,B端的商业模式,都是怎样的情况。

    B端产品如何0-1构建流程:

    商业模式架构 – 业务需求挖掘 – 业务需求转化系统功能 – 产品功能搭建 – 项目资源管理 – 数据分析

    本期重点讲述 -B端系统 – 商业模式架构。

    商业模式:咋一听,这个词好高深,是我这个级别应该接触的吗? 哈哈;

    其实商业模式没有那么高深,你懂了就会觉得sorry easy ;先看看官方怎么讲的:

    商业模式(百度百科):是管理学的重要研究对象之一, MBA、EMBA等主流商业管理课程均对“商业模式”给予高度的关注。在分析商业模式过程中,主要关注一类企业在市场中与用户、供应商、其他合作伙伴(即营销的任务环境的各主体)的关系,尤其是彼此间的物流、信息流和资金流。

    不过,嗯,嗯、确实看不懂;

    对于B产品经理来讲,我是这么理解的:

    商业模式:针对什么样的用户、提供什么样的产品、通过什么渠道触达、如何盈利变现;

    比如聚水潭SaaS软件:针对做电商的商户,提供管理货品拉单发货的系统,通过线上营销线下推广方式触达客户,最终以订阅服务付费的形式实现盈利;

    商业模式:市场定位、竞品分析、用户分析、付费模式;

    一、市场定位

    市场定位是企业及产品确定在目标市场上所处的位置,或者在目标消费者心目中相对于竞争产品而言占据的位置; – 用户心智;

    市场定位四要素:行业、用户、行业痛点、解决方案定位;

    如何快速认识行业:行业现状、发展趋势、竞争对手、行业规模;

    1、行业现状:核心用户,需求满足程度;

    2、发展趋势:年增长率、行业渗透率、相关刺激制约因素;

    3、竞争对手:竞争数量、是否有头部和垄断品牌;

    4、整体规模:行业规模数据、企业数量交易规模;

    信息获取渠道:199IT、发现报告、国研数据、艾媒数据;

    痛点金字塔结构:完成业务模式闭环、提效、降本、控制风险、体验、营收;

    TOB产品的三种产品解决方案定位:

    ①轻量型工具类(服务市场的蚂蚁搬家);

    ②业务解决方案类产品(OA ERP HR );

    ③行业解决方案类的产品(小鹅通、二维火。);

    二、竞品分析

    1、研究竞争对手,找到共性,结合自身业务,搭建解决方案;

    找到竞品优势,特性,分析;自己产品再去打差异化;

    2、找到切入点,和差异化;

    竞品获取方式:

    1、百度搜索 – 行业关键词;

    2、企业网站:36氪企业服务点评、CSDN企业服务导航、选型宝、字母点评网;

    竞品分层:标杆产品、优势竞品、劣势竞品、同目标用户、同细分领域、同行业领域;

    竞品分析:

    1、公司背景:背景、团队、资源、融资;

    2、战略定位:行业、客户、痛点、解决方案;

    3、产品分析:场景、功能;(方法论抽丝剥茧,层次递进);

    • 分析客户(客户是谁)、业务目标、做了那些手段、解决什么、如何解决;
    • 竞品为什么要做,我们要不要做,他解决了什么问题,怎么解决的?
    • 单纯分析页面和功能是没有意义,没有高度;

    4、运营策略:销售定价、整合营销;(线索获取、销售转化、客户成功);

    最终对竞品归纳总结,竞品的优势是什么、最大核心卖点;

    找到自己的差异化定位,切入市场; 或某些功能上进行赶超;

    三、用户分析

    用户不等于客户;

    客户代言人和决策者决定购买;

    四类用户参与:项目发起人、终端使用者、最终决策人、周边支持团队;

    每个角色都有自己角色的核心考虑点和核心目标;

    客户核心述求:完成业务模式闭环、增加效率、降本、控制风险、提升服务、提升营收;

    快速了解客户:客户打标、客户画像分析,用户需求定位;

    对客户走访、case收集 – 形成客户案例池 – 客户打标 – 根据标签总结客户特征;

    一个客户或公司系统

    商业模式画布:重要伙伴、关键活动、核心资源、价值主张、客户关系、渠道通路、客户细分、成本结构、收入来源;

    内部组织流程理解:组织部门架构; 组织部门的目标以及对应策略、以及流程;

    核心战略:市场、业务形式、营收规模;

    四、付费模式

    1、软件买断:仅需要一次性付费,可永久使用权;

    比如:财务用友、一些OA等软件;

    2、年付费:属于订阅会员制,每年定期付费,享受产品服务;

    比如:电商SaaS软件旺店通、管家,有赞小程序等;

    3、月付费:也属于订阅制;

    比如:云服务器、AI使用软件等;

    4、按需付费:只需要用多少付多少,根据需求量收取;

    比如:开放平台接口的调用;

    5、分层定价:根据用户需求不同,可以选择不同价格的服务;

    比如:有赞小程序,就有普通版、专业版、旗舰版等等之分;

    6、定制服务:根据客户需求,给与定制化的策略,并收取对应费用;

    比如神策数据就支持根据客户需求,给出定制的方案;

    7、附加服务:提供基础服务外,同时还提供附近服务,如培训、咨询等;

    ……..

    总结:商业模式日常工作中,我们这个级别参与的确实不多,但大辉认为,总有能用的那一天,所以提前学习布局才能未雨绸缪;

    况且我们了解了商业模式架构之后,自己的视野就会开阔很多,看其他产品会更透彻通透;

    本文由 @阿辉 原创发布于人人都是产品经理。未经作者许可,禁止转载

    题图来自Unsplash,基于CC0协议

    该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

  • 产品架构图,终于有人讲明白了

    产品架构图,终于有人讲明白了

    点击蓝字,关注我们



    产品设计过程中,产品架构图是较常见的图像,在了解什么是产品架构图之前,我们先来说说架构图。


    架构图

    架构图是一种可视化图形,用于描述系统的结构、组件和它们之间的相互关系。即架构=组件+结构+连接,将系统要素按照特定结构进行连接交互。


    它通常用于软件开发和设计,但也可以用于其他领域。一般来说,架构图可概括为7种,他们之间的区别和联系如下:



    下面对这7种架构图进行描述。


    1

    业务架构图

    从业务角度出发,将企业或组织的业务战略、业务流程、业务数据、业务规则等转化为可以理解的架构视图,以帮助企业或组织更好地管理和优化其业务流程、信息系统和基础架构。



    2

    产品架构图

    关注产品的功能组成、模块划分、系统间的关系等,它是以产品为中心,描述产品的功能模块及其之间的关系,以及如何实现产品的设计、开发和测试等。


    3

    系统架构图

    主要关注系统的整体组成结构,包括硬件设备、网络配置、存储设置等方面。



    4

    应用架构图

    关注应用程序本身,包括应用程序的组成部分、功能以及相互之间的交互。


    应用架构图描述应用程序的逻辑结构和组成,以及各个功能模块之间的关联和交互关系,用于更好地理解应用程序的设计和实现。




    5

    技术架构图

    突出技术实现,重点描述系统的关键技术组件,例如分层、核心技术组件、上下游通信方式、数据流向等。


    6

    数据架构图

    描述核心数据模型设计、数据同步和备份的机制等。


    7

    部署架构图

    描述技术部件的物理拓扑结构,重点突出网络、机房、应用以及基础设施的关系。



    什么是产品架构图


    从上面我们可以知道,产品架构图是架构图的类型之一,产品架构图比较关注产品的功能组成、模块划分、系统间的关系等


    它是以产品为中心,描述产品的功能模块及其之间的关系,以及如何实现产品的设计、开发和测试等


    帮助产品经理和开发团队更好地理解产品的组成和结构,以便更好地进行产品设计和开发。



    为什么要画产品架构图


    1

    明确产品方向

    产品架构图可以帮助产品团队明确产品的方向和目标,避免在开发过程中迷失方向或者偏离主题。

    2

    提升开发效率

    通过产品架构图,开发人员可以更加清晰地了解产品的整体结构和各个模块之间的关系,从而提升开发效率。

    3

    方便协同工作

    产品架构图可以让团队成员快速了解产品的全貌和细节,方便不同部门之间的协同工作。

    4

    有利于版本迭代

    产品架构图可以帮助团队更好地规划产品的版本迭代,确保每次迭代都符合产品的整体发展方向。

    5

    降低沟通成本

    通过产品架构图,团队成员可以更加直观地了解产品的设计和功能,降低沟通成本,减少误解和歧义。

    6

    提前规避风险

    产品架构图可以帮助团队提前发现和规避潜在的设计和开发风险,确保产品的稳定性和质量。

    7

    有助于产品宣传

    产品架构图可以作为产品宣传的一部分,帮助客户和合作伙伴更好地了解产品的特点和优势。


    怎么画产品架构图


    1

    梳理业务流程,形成闭环

    产品架构其实是对业务架构的映射,也就是先梳理清楚业务闭环并理清楚逻辑关系才能画出产品架构图。


    业务闭环也就是用户使用产品的闭环流程,基于用户的某个需求或问题


    梳理用户使用的业务流程,梳理参与此模块的用户、角色、场景


    将核心流程完整的表述出来,形成闭环。

    2

    提取业务需求

    基于第一步梳理出来的核心业务流程,根据目标用户的使用路径等,列出每个流程设计的页面、功能模块等。


    在这一步的关键是要想清楚每个业务节点会面临什么样的问题,我们需要设计什么样的页面、功能来解决。

    3

    确定各版块的逻辑关系

    基于以上梳理出来的功能模块,将类似的、相关联的功能以模块化的形式形成一张简单的矩阵图,将功能模块进行聚合分类。


    通常按照交互层(入口)、业务层(具体业务环节)、基础服务层(登录、设置等)、数据层(底层服务或数据)进行归纳整理。



    4

    绘制成产品架构图

    从横向、纵向的角度对产品的功能框架进行梳理。


    首先将明显是同一个范围或同一组的产品功能放在横向层级,得到一个基础的产品框架,


    然后在基础的产品框架基础上,自下而上处理不同架构层级的关系,明确不同产品或系统之间的边界逻辑。


    交互层/入口层包括app、pc管理后台、小程序等多个端;


    业务层将具体的业务单元进行排列,先分清大的并列的业务单元,然后绘制具体大业务单元内的小业务单元的逻辑;


    基础服务层包括了用户、通知、Feed、库存、风控、字典等;


    数据层主要包含数据报表等。





    — END —


    你“在看”我吗?