When business needs are identified and processes are defined it becomes important to identify a business software strategy to support business process execution.
Implementing the business processes in software allows the enterprise to make sure the process is followed, measure it, ensure feedback with respect to both the process itself and regarding its outcomes.
Effective implementation of the business processes in software is absolutely crucial for a digital enterprise to be able to continuously improve, detect changes, transform and respond to new business opportunities as well as threats.
In recent times I have encountered some interesting points for debate. Some startup companies only roughly define their business processes before scanning the market for business software. The idea being that such software solutions generally come with pre-defined processes at least on a lower discipline level, and that they may be adopted straight away by the startup as there are no legacy processes nor legacy data.
I see both pros and cons to this approach, but would love to hear your opinion first.
If we examine some different business software strategy approaches, I would like to focus on the three most common ones.
The monolithic approach:
In this approach, one software solution or at least software from only one vendor is selected. It does have the advantage that, at least in theory, there is a one stop shop for Product Lifecycle Management, Enterprise Resource Planning, Manufacturing Execution System, after sales and services etc.
The downside is that all eggs are in one basket, and it will be difficult to ever change systems.
And trust me, the software provider knows this.
Implementing the business processes in software allows the enterprise to make sure the process is followed, measure it, ensure feedback with respect to both the process itself and regarding its outcomes.
Effective implementation of the business processes in software is absolutely crucial for a digital enterprise to be able to continuously improve, detect changes, transform and respond to new business opportunities as well as threats.
In recent times I have encountered some interesting points for debate. Some startup companies only roughly define their business processes before scanning the market for business software. The idea being that such software solutions generally come with pre-defined processes at least on a lower discipline level, and that they may be adopted straight away by the startup as there are no legacy processes nor legacy data.
I see both pros and cons to this approach, but would love to hear your opinion first.
If we examine some different business software strategy approaches, I would like to focus on the three most common ones.
The monolithic approach:
In this approach, one software solution or at least software from only one vendor is selected. It does have the advantage that, at least in theory, there is a one stop shop for Product Lifecycle Management, Enterprise Resource Planning, Manufacturing Execution System, after sales and services etc.
The downside is that all eggs are in one basket, and it will be difficult to ever change systems.
And trust me, the software provider knows this.
A few core enterprise business systems:
The strategy here is to identify best of breed platforms for major “chunks” of the business process. Examples could be one platform for design and engineering, another for procurement and manufacturing, a third for aftermarket and service. For this setup to work it becomes necessary to spend quite a bit of time and money on integration strategies to ensure that sufficient information flows back and forth between the software platforms. A key enabler here is to define a common language across the enterprise, meaning a Reference Data Library (RDL) of master data classes to ensure interoperability between the software platforms. This will greatly aid integrations as cumbersome data mapping tables can be eliminated in the integrations (Data Integration – Why Dictionaries…..? )
Orchestrated microservices:
The idea here is to utilize central orchestration which manages the interactions and workflows between different microservices while the services themselves are developed to perform the activities.
This approach is flexible and allows for using tools like Kubernetes for container orchestration and workflow engines like camunda and apache airflow for managing business processes. The downside is that it will lead to considerable development to implement your business processes
The idea here is to utilize central orchestration which manages the interactions and workflows between different microservices while the services themselves are developed to perform the activities.
This approach is flexible and allows for using tools like Kubernetes for container orchestration and workflow engines like camunda and apache airflow for managing business processes. The downside is that it will lead to considerable development to implement your business processes
One should always carefully consider the amount of energy and resources put into in-house developed solutions as they will have to be maintained as well as upgraded technically to ensure they stand the test of time both functionality wise as well as from a software security aspect.
Bjorn Fidjeland
Bjorn Fidjeland
RSS Feed
