History Of Business Process Modelling Information Technology Essay

A Functional Flow Block Diagram is a multi-tier, time-sequenced, step-by-step diagram of a system’s functional flow. The functional Flow Block Diagram notation was developed in the 1950’s and was widely used in systems engineering. Functional Flow Block Diagrams are one of the classic business process modelling methodologies. The modern Functional Flow Block Diagram was developed by TRW Incorporated an American defence-related business in the 1950’s and then used by NASA to visualize the time sequence of events in space and flight missions. They eventually became frequently used in systems engineering to show the order of executions for system functions.

Functional Flow Block Diagrams are developed in a series of levels, much like Data Flow diagrams are done today, this allows the same tasks identified though functional decomposition and display them using their logical sequential relationship. Taking for example the way Functional Flow Block Diagrams were used by NASA during space flights, in top or context level of the Functional Flow Block Diagram the entire flight mission can be defined, then in the first level each part can is expanded into a series of different functions describing what each part does, and in the special level each of these are again broken up into further into a new series of functions. This allows the developers to identify the requirements needed.

The overall effectiveness of the process and the extent to which the end result or effectiveness is being obtained if at all will generally be reported on and used as the first measure of the processes adequacy and capability to fulfil the task at hand or which the process has been designed to do, reasonable expectations of the process and it’s uses and operators (staff) should be considered and if necessary implemented in the form of staff training within the S.O.P (process model) if the process model has been designed correctly and adhered to by all it should subsequently be adequate for the purpose intended.

For example, consider the IT service desk. One of its important tasks aside from phone calls is the sub process for end user emails. Such a task is considerably less effective if it does not provide accurate and timely resolutions to its clients; staff in the department responsible for follow up on this would most likely have had to work to comply with an S.O.P (standard operating procedure) which would be an integral part of the business process model. Strict adherence is generally the rule here however there has to be room for out of scope or new issues which can arise. There would generally also be an escalation process (fig2a) set out on different levels depending on if the issue is one where the process failed (hierarchic – escalate to upper management) or if the issue is one that cannot be dealt with by the staff (functional – escalate to a different group within the company’s infrastructure) example of this is where a network storage problem would be dealt with by a functional escalation to a networking group and escalated within that group if necessary whereas a hierarchic escalation might be if cases keep missing on S.L.A. or bad/low customer satisfaction.

Suppose we have observed that the average time taken to deal with and resolve an incident after receiving an email from the end-user is abnormally high, leading to delayed service level agreement and consequent customer complaints, the first thing we would have to look at is the staff reports, if they are implementing the S.O.P and adhering to it, whether the staff / issue which caused the efficiency problems were out of scope or failing that if there is an issue with the implementation of the process (S.O.P) or with the process itself.

The process of end user email’s to creating service tickets would only be as effective as the staff’s knowledge within the area of the issue and if the issue is covered in the process model and whether the issue can be dealt with by first line staff or by an escalation process, generally the efficiency should be to a high standard and not take an excessive amount of time and cost more to the company in the form of hours worked including overtime and lack of productivity of staff members involved. If the case is that too much time is involved with an end user’s issue then the reporting should again be looked at and analysed to see where the efficiency can be improved, if it can where / if not why not?

C: Internal control

Various Internal controls can be built into systems as manual or automated process steps. It is generally a good idea and advisable to build as many internal controls as possible into the system and if possible to automate these where possible, as to err is human, these controls are mainly automatic they will always be used since they are built into the design of the business process then the relevant software would be used to implement them. An example of this would be the automated response while trying to log on to a network without you having a valid user account, you receive an error message. Another example of this would be an automated response to a service desk email, another form of automation and internal control is where you can automate in the sense of detective work where your staff will receive automated responses from business software referring to breech of Sla and thus making case prioritizing and certain escalations automated.

However, for various different reasons such as out of scope, lack of training or knowledge and experience, difficulties in designing/writing software, cost of software development and modification, there needs to be a certain amount of flexibility, but the problem arises with the incapability of a computerised system to provide all internal controls and be flexible to the extent to be still able to deal with the unknown issue’s, a lot of internal controls generally considered to be a necessity are often excluded from business systems and software . In such an instance, the manual process of internal controls outside the business system but within the business process should be clearly documented, maintained and regularly exercised by those who will be in a position of having to implement them. unfortunately with the lack of such a system based internal control, errors often occur and therefore the item creation process must include an administrative control through the process of checking, by person’s trained in the process and with the knowledge and experience to do so competently. Of course with the use of manual internal controls you must have and in general it would probably be legislation that you have your internal controls up to date and audited regularly by a higher authority.

D: Compliance to various laws and policies

Compliance to laws and various standards can be and is generally different from country to country, the usual way company’s stay compliant with these would be by the use of and implementation of policies and practices generally in the form of good doc practice guides, training and testing of staff on a regular basis and probably regular meetings to stay up to date on new issues, controls and policies. Usually all organization and company’s enforce this by engaging directly at the appropriate level where it is required and with plenty of communication to all levels. policies in general should cover things like information security which can be from one single pc to corporate networks and the inter-connections which exist between them, another area which is usually misunderstood and underutilised is document retention policies, a simple and clear non haphazard document retention policy can mean the difference between a hefty fine from a governance body and complete indemnity if a situation ever was to arise that involved the company’s/organisations staff,

with the infrastructure and resources we have in place these days there is no reason for records not be maintained as accurately as possible, you should be able to access them as and when needed, they should also be stored securely for the duration that the policy or higher authority dictates.

Figa : Escalation Process (example of a business process model in action)

Modern Business Process Modelling Techniques

Gavin Kenna – X00083664

Business process modelling (BPM) in systems engineering and software development is the activity of representing processes of a business, so that the current process may be analyzed and improved. Before the 1970’s, business process modelling techniques included the Gantt chart, PERT diagrams, IDEF and Control Flow Diagrams. But, more recently more updated and improved techniques have surpassed these older techniques and are now the standard. Most process modelling is now done through what is known as business process modelling languages. Most modern business process modelling languages are either graphical or textual.

An example of a graphical modelling language and a corresponding textual modelling language is EXPRESS.

EXPRESS

EXPRESS is an international standardized data modelling language and is ISO Standard for the Exchange of Product. An EXPRESS data model can be developed in two ways, textually and/or graphically. For textual modelling, EXPRESS relies on the old ACSII standard to render the data into text. Graphically, however, EXPRESS offers EXPRESS-G, which has the same functionality as EXPRESS, but with a user friendly GUI, which enhances productivity and efficiency. Express has been compared to the programming language Pascal, which is an Object Oriented programming language.

EXPRESS-G_diagram_for_Family_schema.png

Figure a: An example of an EXPRESS data model

There are basically two aspects to EXPRESS:

It allows for the modelling of data and data relationships with a very general and powerful inheritance mechanism, more so than object oriented programming languages, such as C++ and Java.

It uses a fully fledged programming language, which adds more productivity for the user, as it allows them to fine tune how their data is stored, executed, etc.

Unified Modelling Language (UML)

Unified Modelling Language is a standardized general purpose modelling language used in the field of software engineering. UML, unlike EXPRESS, is more graphic based than textual.

UML is a de facto industry standard and is used very often in the software industry today, mainly because of its ease to use, and for new users to grasp very quickly. UML is used to develop and document the artifacts of an object-oriented software system under development. UML is very visually focused, and as such relies on elements to visualize a systems architectural blueprint. Elements in which UML use include:

Actors (stickmen to portray human interaction with the system)

Business Processes

Database Schemes

Programming Language Statements

Data Flows

UML_Diagramme_Deploiement.gif

Figure 3b: This is a component diagram drawn in UML

UML can be used with all processes, throughout the software development life cycle and across implementation technologies. UML has been adopted into Microsoft’s Visio, which is now part of the Microsoft Suite.

Business Process Modelling Notation

Business Process Modelling Notation (BPMN) is a graphical representation for specifying business processes in a business process model. The Business Process Modelling Notation (BPMN) is a standard for business process modelling, and provides a graphical design for specifying business processes in a Business Process Diagram based on a flowcharting technique very similar to diagrams in UML. The purpose of BPMN is to support business process management for both technical users and business users by providing a notation that is easy to business users yet able to represent complex process semantics. The main goal of BPMN is to provide a standard notation that is understandable by all business stakeholders.

Like UML, BPMN is very visually focused, and as such relies on elements to visualize a systems architectural blueprint. Elements in which BPMN use include:

Events

Activities

Message Flow

Data Object

Annotations

Processes

BPMN has been criticized recently for a number of reasons. A few of these reasons include:

Ambiguity and confusion in sharing BPMN models

Lack of support for routine work

Lack of support for knowledge work

BPMN-AProcesswithNormalFlow.jpg

Figure 3c: An example of a BPMN process flow.

Data Flow Diagram (DFD’s)

A data flow diagram is a visual flow of data through a computer system. DFD’s are also used for the visualization of data flowing from one process to another. On a DFD, data (such as a customer’s name and address for example) flows from either an external or internal data store to a process , which then processes the data to perform a certain action, such as purchasing a product, paying bills etc.

In each DFD, there are 3 Levels:

Context Level

Also known as Level 0, this level contains very little detail, but is used to show stakeholders how the system will work without going into too much detail. The context level showcases the system’s interactions with the outside world.

Level 1

On Level 1, the DFD is expanded upon into much greater detail, and deals with processes and data flows. Level 1 DFD shows how the system is divided into processes, each of which deals with one or more of the data flows to or from an external agent (database, user information etc.).

Level 2

Level 2 is also referred to as the low level diagram, as it solely focuses on one process in particular. This one process is explained in great detail. As it focuses on one process in great detail, this information is relative only to a selected number of stakeholders, namely the systems analysis and the programmer assigned the job of developing this certain process.

800px-DFDC.png

Figure 3d: An example of a Context Level DFD.

800px-DFD1.png

Figure 3e: An example of a Level 2 DFD.

References

Fig1 : referenced at http://en.wikipedia.org/wiki/File:Business_Process_Management_Life-Cycle.svg

Fig1a : referenced at http://wordsmithbob.com/blog/wp-content/uploads/2008/11/gantt-chart-your-most-important-client-or-customer-is-you.gif

Fig1b : referenced at http://en.wikipedia.org/wiki/File:Pert_example_network_diagram.gif

Fig2a : referenced at http://edocms.com/directories/ITIL/Summary-Notes.html

Fig3a : referenced at http://en.wikipedia.org/wiki/File:EXPRESS-G_diagram_for_Family_schema.png#file

Fig3b : referenced at http://en.wikipedia.org/wiki/File:UML_Diagramme_Deploiement.gif

Fig3c : referenced at http://en.wikipedia.org/wiki/File:BPMN-AProcesswithNormalFlow.jpg

Fig3d : referenced at http://en.wikipedia.org/wiki/File:DFDC.png

Fig3e : referenced at http://en.wikipedia.org/wiki/File:DFD1.png