我为DPMBoK准备了内部方法论材料。在我看来，今年春天大家都清楚，今天几乎没有业务需要进行数字化转型，而这篇文章可以使对此主题感兴趣的每个人都保持最新状态，或者在评论中进行有趣的讨论。
任何在增长过程中基于数字业务要素（数字产品或服务，平台，生态系统）的企业都将面临减速或缺乏计划扩张的时刻，而这些时刻从“经典”管理的角度来看是不合理的。这些时刻可能由许多因素（障碍，限制）引起：外部或内部，技术或组织，可解决的或乍看之下不可克服的。在可以尝试解决方案的特定行业中，某些障碍是典型的。并且可能会出现与业务模型或行业无关的限制。这种情况的解释是，具有重要IT组成部分的数字产品是具有高度复杂性的社会和技术系统。它的意思是，他们的组件或互动的微小变化会严重影响他们的整体行为和价值。
最不愉快的是，这种限制类似于牙痛-他们早就知道，不必钻孔或去除。尝试使用Internet论坛来诊断您的企业时，专业站点通常是一种有效的方法，但劳动强度很高。寻求专业顾问和专家是一件好事，而且很可能是正确的选择。但是在这种情况下，最好“成为主题”或通过学习别人的经验来事先做好准备。
我和我的同事们在战略发展和数字化转型（在“ LANIT-Integration”公司中运营）的中心从事数字企业的创建和运营，并长期形成了我们咨询项目的方法论基础。然而，我们对这一知识体系的互补性和完整性感到惊喜。如今，阅读现代商业文献通常是一项不费力的任务-资料太多，很难找到您需要的东西。各个版本的含义可以用八行文字表示，其中95％充满了以短文形式（如本文）列出的历史和个人旅行。
许多出版物专注于数字产品创建，团队合作或技术挑战的特定问题。
长期以来，市场上没有涵盖数字企业各个方面的出版物。但是，正如他们所说的那样，``一个圣地永远都不会是空的''，The Open Group的一组作者在2019年提出了数字实践者知识体系的第一版，该版本试图采用所有相关方法来解决最典型和重大的挑战。出现在数字企业的所有者和雇员之前。
该集合不仅是方法和术语的本体，而且是数字企业一致声明的路径，并公开了由实际团队和公司使用所述工具包的实践经验。
保管库本身有两种格式可用：
- 互联网门户网站（对于那些很难理解英语的资料并可以使用浏览器翻译功能的人来说，这将很方便，但是最好同时了解原始语言），
- pdf版本可在注册后下载。
顺便说一句，门户网站的存在并不是The Open Group的想法。作者在DPBoK的基础上提出的其中一项原则说：“知识体系本身必须作为数字产品存在和发展。开发人员应该对受众结构，交付渠道的有效性有清晰的了解，开发本身应该以一定的速度进行，并且内容应该由于反馈和与受众的互动而改变。“
该法典由六个部分组成，实际上前五个部分是介绍性的。他们披露了创建的原因和目的，并提供了使用指导。
作者提供了非常明确的论据，说明为什么数字化的开始迫使公司重新考虑自己的业务模型和策略。
保管库的许多元素都建立在The Open Group先前创建的材料上。关键材料之一是组织变革的七个杠杆原则-建立数字企业所需的基本要素：
- 业务流程的转变；
- 客户体验和互动；
- 产品的数字化转型；
- IT和产品实施流程的转换；
- 组织文化;
- 战略;
- 生态系统和商业模式。
展望未来，值得注意的是，DPBoK包含许多对其他知名标准和知识准则的引用，这突显了作者不愿为出现的每个问题重新发明轮子，同时又要保持完整性和覆盖范围。
作者指出，实际上，创建数字产品的现代方法不应与经典方法相对。任何经过时间和社区测试的工具包都可以在一段时间内以适当的企业规模使用。
第六，它是根据扩展数字企业计划而构建的知识体系的主要和最丰富的部分：从初创公司创始人的任务到数字公司的问题。
数字企业发现自己的每个阶段都包含有关最相关问题的知识部分以及解决方案。
| 可持续企业 | 建筑方法 |
| 信息管理 | |
| 治理，风险管理，信息安全，合规性 | |
| 团队团队 | 文化与组织 |
| 融资产品组合 | |
| 流程方法与管理 | |
| 命令 | 技术运营管理 |
| 工作管理 | |
| 产品管理 | |
| 创办人 | 申请交付 |
| 数字产品基础架构 | |
| 数码产品基础 |
第一个上下文（“创始人”）介绍了创建数字产品所需的基本知识和技能。在很大程度上，所提供的材料与精益启动原则相一致：产生想法，收集和测试假设，用户反馈，创建计划-构建-运行周期。 Digital Foundations部分提供了一个图表，该图表对于理解为客户创造价值的机制非常有用，其中包括数字产品生命周期的概念（想法>投资>开发>变更>交付>使用>支持>恢复>改进/退出） ...
在上下文中，给出了组织启动数字产品所需的技术基础结构的当前方法，包括虚拟化，云和混合基础结构的使用，容器和基础结构即代码机制的问题。
对于甜点，此上下文邀请您熟悉敏捷应用程序开发和交付工具。尽管对迭代开发模型和DevOps的开发原因进行历史考察可能很有用，但是Habr的普通读者不太可能在这里找到新的东西。
第二种情况包含了小型团队有效工作所需的一组技术和工具，这些团队需要自己的产品，包括产品，工作和运营管理（“基础设施”并未被遗忘）。
自从总体移动性问世以来，很明显，专注于创建产品的技术部分的团队需要具备管理其消费者价值的能力。了解市场，不断寻找用户需求并响应反馈与产品实施和交付同样重要。
这些问题在产品管理基础知识部分中得到了解决。这里有许多有用的技术。例如，沿着“数据>洞察力>信念>犯罪率”链构建的DIBB模型将显示假设检验机制的重要性。熟悉“即将完成的工作”产品研究方法和“设计思维”概念也将很有帮助。
的工作该代码的作者并没有采用与确定未来产品需求相关的经典方法，这些方法是在另一个专门的知识体系BABoK中制定的。
尽管普遍遵循精益产品开发方法，但作者指出了这些方法的适用性方面存在的局限性。并非所有产品都是社交媒体（鲜花），A / B测试效果很好。仍然有很大一部分系统工程产品（齿轮）需要详细说明需求。
产品开发问题的合乎逻辑的延续是工作管理的主题：产品开始需要完成各种各样但相关的任务的时刻。
在这里，DPBoK的作者采取了一项重要的行动-他们解释了产品概念与开发所有相关敏捷和精益方法的概念之间的关系：定义“完成”的概念，管理任务队列，减少“未完成”，根据滞后指标的成本对任务进行优先级排序（财务方面可以对工程师和产品工程师都是有用的）等。
精益产品开发是同样宝贵的资源。程序员的古老观点是“开发是一个创造性的过程，其时间框架无法确定”，在精益产品和过程开发方法中被驳斥。精益产品和过程开发方法是一套有效的方法，有助于在开发的各个阶段不浪费宝贵的时间，建立透明且可预测的过程。许多技术来自日本汽车业的经验，这些经验经受了时间和市场的考验。
关于“操作”（可能会说“基础设施维护服务”，但这种翻译不能完全反映术语“操作”的含义），第二种上下文不仅定义了，而且还描述了“操作”与产品生命周期和用户体验之间的关系。它还定义了服务级别，系统配置，媒体管道和遥测的概念。所有这些都是用一种系统管理员无法理解的语言来陈述的，并且可以帮助创建数字产品的整体构想。
熟悉技术扩展原理（CAP和AKF）的有用性几乎不能被高估：被产品开发和实施过程所吸引，有时您会发现自己对系统负载问题感到困惑。
转到第三个上下文“团队团队”，我想指出的是，这一水平仅是几十家国内知名公司的特征。但是，尽管上下文充满雄心，但其内容对于已经开始不仅考虑单独的数字产品，而且考虑整个企业的开发的专业人员和企业家也将是有用的。
在此阶段，团队协作，财务管理以及文化和组织问题更可能成为第一位。实际上，我们可以说，这些不仅是数字企业的主要管理问题，也是经典管理的主要问题。不能忽视弗雷德里克·泰勒（Frederick Taylor），爱德华·德明（Edward Deming），彼得·德鲁克（Peter Drucker）和其他劳工组织领域的实践科学家的工作。但是在这种情况下，The Open Group的作者并没有通过长时间的研究来折磨读者，而是对科学的劳动力组织对于数字企业成功的重要性提供了紧凑而合乎逻辑的解释。
财务方面的介绍不会伤害任何人。作者没有将财务部分放在前列。是的，企业必须为其所有者带来利润。但是，该规则并不违背数字产品的愿景和发展。
成本计划，基于最佳需求的决策，吸引投资，定价的方式以及获取外部服务和服务-这些不是闲置的问题，它们需要理解和解决方案的方法。
本部分经常介绍最著名的可伸缩敏捷方法之一-SAFe，它本身应该提供完整的系列文章，并且目标设定和工作定义基于财务绩效。
组织上下文部分按以下顺序组织：从组织结构及其在招聘过程中的填充到最复杂的组织文化问题。
实际上，第四个上下文描述了主要的数字企业联盟的存在性问题：Yandex，Google和Facebook。这是否意味着此部分对小型组织没有价值？没门！关键是，这种规模的企业不再作为孤立的系统存在。它们为其他数字企业的发展提供了平台和生态系统。一旦熟悉了可持续企业的背景，您就可以理解（并原谅）以前认为是异想天开和官僚作风的Bigger的要求，将您的期望调整为它们，并建立更有成效的互动。
那么为什么值得读DPBoK
首先，它很漂亮。其次，DPBoK提供了与数字企业的创建和发展有关的可理解且有价值的知识，可以快速访问以应对新出现的挑战。第三，您可以获得关于当前良好实践的最佳参考，以及有用的见解和重要的历史参考，可以使您对当前时刻有更全面的了解。
希望这些材料将对您建立数字企业的旅程有所帮助。如果您有任何问题，我将很乐意在评论中回答。
我们的空缺