Synopsis: In any organization, there is an abundance of knowledge, which is spread thin across people, business processes, technical systems, products, services, and solutions. Consequently, decision-makers lack the knowledge needed to be effective and drive meaningful digital transformations or optimize efficiency. Therefore, it is imperative to centralize your enterprise knowledge assets by making them accessible for both contribution and consumption.
Figure: knowledge graph, consisting of clusters of different information bits, connected across an enterprise.
Knowledge is abundant in any organization, and it's spread thin across people, business processes, technical systems, products, services, and solutions. Such a distribution is natural because an enterprise participates in almost countless activities to deliver on its business objectives and delight customers.
For example, a company may manufacture physical products, provide services and goods to its customers, and even develop digital applications. For these business units to operate, such an organization would hire thousands of employees who participate in hundreds of processes and interactions. The necessity for multiple subject matter expertise will naturally develop social gatherings where the knowledge accumulates and stays in silos. As an example, a manufacturing department engineer has different bits of information than the software systems developer. Even those who designed business processes will not have the context of all participants in those processes.
In the kind of enterprise we described above, you will need to gain a certain level of visibility into all the listed business units to make any meaningful large-scale decision. How do you achieve this objective without talking to a lot of people? By "a lot," we mean hundreds, if not thousands of respondents.
For example, you might be interested in identifying and sunsetting legacy software systems that have a minimal impact on your manufacturing processes. The statement is straightforward as it's written, but you need quality input and analysis to accomplish this task.
On the one hand, you will need to understand how manufacturing works and related processes. From there, determine who participates in those processes and how they use software systems for this purpose. On the other hand, you need an inventory of software systems, runtime and deployment models and locations, development and maintenance teams and policies, and technical SMEs.
Regarding the described problem, you might be thinking of talking to several business units' leads and giving them the strategic mission of identifying and sunsetting the legacy systems. While this approach could lead to some results, it is the least desirable because it would disrupt a big part of your enterprise. The responsible parties will have to interview all employees who may have the necessary information or be impacted by the change. It is not easy to complete this exercise in a reasonable timeframe due to the disconnected nature of knowledge.
For example, an employee in the manufacturing unit may not realize that her software has a different official name within the software engineering organization. Such disconnected pieces of knowledge need to be connected and reconciled. Often, big groups of people need to gather to understand the problem statement and context before tackling it. Even after such working sessions, it is frequently impossible to be sure about the outcomes.
Due to the mentioned complexities, we consider the above approach obsolete in today's world.
Let us suggest what we consider a modern solution to the described problem - a centralized knowledge asset repository.
The idea is straightforward: imagine every SME and employee contribute to the unified knowledge database. At the same time, each contributor has access to the already available information from other employees. Knowledge is exhaustive on the one hand, and it is reconciled and singular on the other hand.
For example, a manufacturing unit SME would leverage access to the IT department's inventory of software systems and have reconciled the alias she uses against the proper name of the application. Alternatively, the software engineering SME would notice an unknown system listed in the inventory and learn a name mismatch between the units that develop and consume the digital asset.
More importantly, the centralized knowledge asset repository allows anybody to quickly understand the usage and impact of applications on the manufacturing business processes and products. The only prerequisite for this exercise is the structured knowledge that one can parse and analyze with minimal effort.
We realize that you can store your knowledge in many forms and shapes. However, not all of them are equally effective and helpful when analyzing and reconciling knowledge.
Textual repositories (e.g., Confluence or Sharepoint) where you store your enterprise documentation are heavier than necessary. They often lack visuals and links to quickly absorb large amounts of data without opening and reading many documents. If you opt into visual drawing tools (e.g., Visio or Draw.io), they will not satisfy your needs. Such diagrams serve a one-time purpose since they quickly become stale once your organization undergoes any significant change.
It would be best if you had something in between - visual, reusable, and descriptive. Now we are entering the niche that Archipeg occupies.
Archipeg Architecture Cloud (or just Archipeg) allows you to invite all your SMEs into a single platform to contribute and consume the centralized knowledge. Since our product is based on a reusable object model, you can reconcile conflicting bits of information and avoid throw-away work with data-driven diagrams. Furthermore, you can describe various initiatives in separate projects, each having an isolated object model. These capabilities together make your large-scale knowledge management scalable, accessible, and consumable.
Start today with a free 30-day trial and transparent prices. If you need our assistance, reach out to us at any time.