A Business Model describes the rationale of how an organization creates, delivers, and captures value, in economic, social, cultural or other contexts. The process of business model construction and modification is also called business model innovation and forms a part of business strategy.

In theory and practice, the term Business Model is used for a broad range of informal and formal descriptions to represent core aspects of a business, including purpose, business process, target customers, offerings, strategies, infrastructure, organizational structures, sourcing, trading practices, and operational processes and policies including culture.

We discuss the “Internet of Things” (IoT) or the Digitization of Business Processes. Both include technical solutions as well as the business view.

IT has to be “business aware” the same way as business has to be “technology aware”. Business and IT together need to eva luate the use of technologies for better business solutions solving business problems.

System descriptions, system requirements, connection between systems and business capabilities are in the scope of Model-Based Business Engineering. Special requirements for Business-IT-Systems are part of the approach. The development and description of the systems is not in focus. Different model-based approaches exist for this as the Model-Based System Engineering (MBSE). We understand Model-Based Business Engineering as complementary to such approaches.

We Understand Model Development For Business as an Engineering Discipline. This means:
• We can plan it
• The quality of our models can be measured
• Model development is comprehensible and repeatable
• Models can be maintained and used long term
• Design decisions are made with a reason

This should be obvious but isn’t so in daily practice. The request to produce models in a comprehensive and repeatable way causes discussions. We expect that the resulting models are comparable if they are based on the same information independently which team member created them. Modeling is a creative activity. The models will not be identical. We maybe do different design decisions resulting in different models. That’s why capturing this information is essential.

Business Engineering is not a one-time effort. Processes and capabilities need to be improved continuously to stay competitive. We monitor processes and measure key performance indicators based on our models. We change processes and capabilities based on this results.

Continuous Improvement of Business Processes And The Organizational Context bring the danger that models and reality are no longer in sync after some time. We have to make sure both stay in sync or we risk to lose our investment in the models. Hence, we define Governance Rules and processes for the maintenance of our models. Governance may be the most advantageous aspect of any type of business model.

Business Process Re-Engineering (BPR) is a business management strategy, originally pioneered in the early 1990s, focusing on the analysis and design of workflows and business processes within an organization.

BPR is aimed to help organizations fundamentally rethink how they do their work in order to improve customer service, cut operational costs, and become world-class competitors. BPR seeks to help companies radically restructure their organizations by focusing on the ground-up design of their business processes.

According to early BPR proponent Thomas H. Davenport (1990), a business process is a set of logically related tasks performed to achieve a defined business outcome. Re-engineering emphasized a holistic focus on business objectives and how processes related to them, encouraging full-scale recreation of processes rather than iterative optimization of sub-processes.

Business process reengineering is also known as business process redesign, business transformation, or business process change management.

In information technology (IT) project management, there are different project management methodologies, Waterfall and the Agile Frameworks.

The traditional methodology, Waterfall has a much more structured format and could be less adept for new and upcoming industries which tend to be more flexible. This is where the Agile framework take the lead and are more nimble. Change Management is handled differently in an Agile environment versus a Waterfall environment.

In a Waterfall environment, the phases involved would be Initiate, Plan, Execute, Monitor and Control, and Close. In this case, not much can be done once an issue presents itself during the project, and if something needs to be done to the project to fix any issues, the timeline of the entire project could be pushed back which could have other effects on the budget. 

A Change Request can be submitted to address the change. When the change request form is submitted, it is then reviewed, impacts to the budget, scope and schedule analyzed before it is approved and then implemented.

In an Agile environment, the approach is very different, and makes use of the iterative process to manage changes more efficiently. If a change is discovered during a Sprint, it is recorded as a Product Backlog item and placed in the Product Backlog. From there, it is prioritized and estimated for a future Sprint.

Change Assessment and Monitoring in an Agile Environment

When managing the change logs in an Agile environment, it is a continuous process, and is assessed for each sprint. The issues are being assessed in the beginning of the meeting, brainstorming of some mitigation processes, and all of that information is recorded and accounted for and can be used in the next sprint. 

The Agile team does a group brainstorming session to discover what might occur in the project and is followed by an analysis of why each event may occur. After the changes have been identified, they are recorded in the Product Backlog and be accessible to the members of the team. If something is omitted, missed, or skipped, it is easier to spot it, account for it, or it is brought up again in an upcoming sprint. If an issue is not accounted for during one sprint, it can be caught and brought up during the next sprint. 

The change prioritization makes it a lot manageable as a risk or an issue that is prevalent in this sprint can be taken care of in a short time, and much more efficiently while checking to see that it has been mitigated several steps before the final product. The change can be handled quickly and efficiently such that the over timeline of the project stays the same.