<discussion ref="http://mainthing.ru/item/208/" />
Generally agree with your conclusions - just a few random comments:
a) historical — workflow was originated within ERP systems to improve their flexibility; but often such a workflow is not visible. Effectively, BPM offers the externalization of workflow, so, BPM and ERP are very complimentary;
b) methodological — in the absence of an agreed reference model for BPM it is difficult to compare impact of different BPM implementations;
c) managerial — popularity of ERP is based in the long-term practices of US management to focus primary on the stock optimization. At the same time Japan was developing process-oriented practices;
d) architectural — re “Of course it’s impossible to say which way is better - a unified system from a single vendor or the integration of various \“best of breed\” systems”. I think, a network effect should be used as a guidance — moving from the former to the latter decreases efficiency and increases effectiveness. So, choose what you need now.
Thanks,
AS
2009-08-25
Practical process patterns: SI and SOS
As an addition to my webinar about BPMN, I uploaded on slideshare.net two practical process patterns:
1. Submission Interface (SI) - http://www.slideshare.net/samarin/process-practical-patterns-si
2. Synchronisation Of Sources (SOS) - http://www.slideshare.net/samarin/practical-process-pattern
These PPTs should be donwloaded to see animations.
Thanks,
AS
1. Submission Interface (SI) - http://www.slideshare.net/samarin/process-practical-patterns-si
2. Synchronisation Of Sources (SOS) - http://www.slideshare.net/samarin/practical-process-pattern
These PPTs should be donwloaded to see animations.
Thanks,
AS
Labels:
BPMN,
practical process patterns
Linkedin: Failure to manage processes can become expensive
<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1062077&discussionID=6365776&commentID=5952169#commentID_5952169" />
I think, this is an example that the use of BPM is repeating "Pitfalls of automation" (see a good article in http://www.geocities.com/CapeCanaveral/Hangar/2883/automate.html ). Another sign of this repetition is some discussions about human processes vs automated processes.
In my experience, there are neither only human processes nor only automated processes. Each automated activity within a process should be encapsulated into an "error-recovery loop" which may include a human activity. For example, a fully automated conveyer at a car factory has some side lines to "do" some cars manually.
A fully "automated" process may have a human task to watch the process - in the same way that an observation window allows one to observe the workings of a turbine.
Each human activity is surrounded by automated activities - similar to a good secretary who prepares documents for a boss and later takes care about them.
So, to comment Thomas' list:
- Don’t only rely on automation,
-- more automation requires adequate controls (also automated)
- augment it with appropriate process management methods,
-- In addition to production (or horizontal) processes, I recommend to develop some controlling (or vertical) processes; the latter helps people to validate execution of production processes.
- define proper rules for process managers that don’t only cover system functionality but also address process results,
-- controlling processes may signal potential problems to humans as well as propose some adjustments. For example, an assurance company guarantees that each claim is processed in less than N days (i.e. there is an SLA) and claims over 50$ are checked manually; when this company receives a wave of claims, a controlling process by detecting this wave may propose either to increase the staff for checking those claims or to adjust a limit (from 50$ to 100$) so more claims will be treated without manual check.
- responsibility and accountability should play equal parts in process management jobs and should address clearly defined processes,
-- who is responsible for a process template, a process instance, a process activity.
- don’t design your processes for the sunshine case only – also look at process risk management issues.
-- fault-tolerance, error-recovery, comprehensive traceability, etc. are important for BPM design and execution; actually, the power of BPM helps us to address those issues in different ways, e.g. if a problem is caused by a user then a super-user may receive a task to resolve this problem.
Thanks,
AS
I think, this is an example that the use of BPM is repeating "Pitfalls of automation" (see a good article in http://www.geocities.com/CapeCanaveral/Hangar/2883/automate.html ). Another sign of this repetition is some discussions about human processes vs automated processes.
In my experience, there are neither only human processes nor only automated processes. Each automated activity within a process should be encapsulated into an "error-recovery loop" which may include a human activity. For example, a fully automated conveyer at a car factory has some side lines to "do" some cars manually.
A fully "automated" process may have a human task to watch the process - in the same way that an observation window allows one to observe the workings of a turbine.
Each human activity is surrounded by automated activities - similar to a good secretary who prepares documents for a boss and later takes care about them.
So, to comment Thomas' list:
- Don’t only rely on automation,
-- more automation requires adequate controls (also automated)
- augment it with appropriate process management methods,
-- In addition to production (or horizontal) processes, I recommend to develop some controlling (or vertical) processes; the latter helps people to validate execution of production processes.
- define proper rules for process managers that don’t only cover system functionality but also address process results,
-- controlling processes may signal potential problems to humans as well as propose some adjustments. For example, an assurance company guarantees that each claim is processed in less than N days (i.e. there is an SLA) and claims over 50$ are checked manually; when this company receives a wave of claims, a controlling process by detecting this wave may propose either to increase the staff for checking those claims or to adjust a limit (from 50$ to 100$) so more claims will be treated without manual check.
- responsibility and accountability should play equal parts in process management jobs and should address clearly defined processes,
-- who is responsible for a process template, a process instance, a process activity.
- don’t design your processes for the sunshine case only – also look at process risk management issues.
-- fault-tolerance, error-recovery, comprehensive traceability, etc. are important for BPM design and execution; actually, the power of BPM helps us to address those issues in different ways, e.g. if a problem is caused by a user then a super-user may receive a task to resolve this problem.
Thanks,
AS
Labels:
architect enterprise BPM systems
2009-08-17
Linkedin: What does mean the term 'Business Architecture' today and what it should mean tomorrow?
<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=84758&discussionID=6110389&sik=1250500606590&trk=ug_qa_q&goback=%2Eanh_84758%2Eana_84758_1250500606590_3_1" />
I would start from the context and a few definitions. (I use below some of my definitions from http://www.samarin.biz/terminology )
In the broadest sense and as already mentioned, an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.
In the case of enterprise, the "roles" from this definition can filled in the following way:
“customer” = top management, senior executives
“wishes, dreams and expectations” = creating a new company, merger, changing of unit’s internal structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc.
“others” = the whole enterprise
An enterprise can be, for example, a business unit or department, an entire corporation, a government agency or a collection of businesses joined together in a partnership. An enterprise can be considered as a system whose parts are people, processes, information and technology. In general it is a complex and dynamic system of systems.
I use a term “enterprise business system” for the top level view of an enterprise as a system for conducting the business. This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals. The issues of greatest importance for enterprise business systems are the following:
• the core end-to-end business processes (also known as value streams);
• the governance structures;
• the core business information (semantics);
• the communication with the core business partners.
Architecture of a system is, in some sense, the main tool to work with the system. Architecture comprises two inseparable parts: descriptive (nomenclatures of artefacts, relationships, etc.) and prescriptive (rules on how to evolve this system). Both of them may be implicit or explicit or somewhere in between. Both of them are used together in “what if” analysis of different changes.
So, “architecture of an enterprise business system” or “business architecture” -- coherent and proven set of principles, recommendations, practices, and tools which provides guidance and practical help for the design and evolution of enterprise business system to achieve enterprise vision and strategy.
Thanks,
AS
I would start from the context and a few definitions. (I use below some of my definitions from http://www.samarin.biz/terminology )
In the broadest sense and as already mentioned, an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.
In the case of enterprise, the "roles" from this definition can filled in the following way:
“customer” = top management, senior executives
“wishes, dreams and expectations” = creating a new company, merger, changing of unit’s internal structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc.
“others” = the whole enterprise
An enterprise can be, for example, a business unit or department, an entire corporation, a government agency or a collection of businesses joined together in a partnership. An enterprise can be considered as a system whose parts are people, processes, information and technology. In general it is a complex and dynamic system of systems.
I use a term “enterprise business system” for the top level view of an enterprise as a system for conducting the business. This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals. The issues of greatest importance for enterprise business systems are the following:
• the core end-to-end business processes (also known as value streams);
• the governance structures;
• the core business information (semantics);
• the communication with the core business partners.
Architecture of a system is, in some sense, the main tool to work with the system. Architecture comprises two inseparable parts: descriptive (nomenclatures of artefacts, relationships, etc.) and prescriptive (rules on how to evolve this system). Both of them may be implicit or explicit or somewhere in between. Both of them are used together in “what if” analysis of different changes.
So, “architecture of an enterprise business system” or “business architecture” -- coherent and proven set of principles, recommendations, practices, and tools which provides guidance and practical help for the design and evolution of enterprise business system to achieve enterprise vision and strategy.
Thanks,
AS
Labels:
enterprise architecture
2009-08-12
A small review of the book “Ladder to SOE” by Michael Poulin
This book (http://michaelpoulinssite.homestead.com/My-Book.html) perfectly reflects the current way of advancing in the computer science – the author is debating a lot of topics with a lot of people. Quotes are thoroughly analysed and supplied by contra-arguments. The whole book is a dynamic discussion similar to the work of an SOA consultant who should be able to discuss any question and any opinion about SOA. Logically the book is stimulating the reader to follow the same rule – debating the author’s position. I found this great. Anyone who is touching SOA should read this book to derive his/her own opinion.
For example, I don’t agree that process is “just implementation” of services – the former are also explicit and executable and understandable by the business. Executable process is the way to make bigger services from smaller services.
Another point – the definition of SOA from OASIS RM which, in my opinion, is more applicable to the modern economy than to construction of software-intensive systems. It is well-known that the business world understood a long time ago that services and processes are the backbones of most enterprise business systems.
Finally, I wish Michael to publish soon next book with his experience about the implementation and evolution of SO enterprises.
Thanks,
AS
For example, I don’t agree that process is “just implementation” of services – the former are also explicit and executable and understandable by the business. Executable process is the way to make bigger services from smaller services.
Another point – the definition of SOA from OASIS RM which, in my opinion, is more applicable to the modern economy than to construction of software-intensive systems. It is well-known that the business world understood a long time ago that services and processes are the backbones of most enterprise business systems.
Finally, I wish Michael to publish soon next book with his experience about the implementation and evolution of SO enterprises.
Thanks,
AS
Labels:
SOA
2009-08-07
How to use BPMN for modeling business processes
A short version of my webinar "How to use BPMN for modeling business processes" is available on slideshare
http://www.slideshare.net/samarin/how-to-use-bpmn-for-modelling-business-processes
Some slides (marked with a small star) include animations. You have to download this PPT file to see these animations.
Thanks,
AS
http://www.slideshare.net/samarin/how-to-use-bpmn-for-modelling-business-processes
Some slides (marked with a small star) include animations. You have to download this PPT file to see these animations.
Thanks,
AS
Labels:
BPMN
Subscribe to:
Posts (Atom)