Introduction This is the third in a series of articles evaluating tools used by process professionals. As with previous reviews, I approach the subject as a business professional with a need to document, analyze, and improve processes, not as an IT professional or a BPMS industry expert – I am neither. My most critical criteria are once again ease of use, a short learning curve, and good collaboration features.
In these tough times, even the most change-resistant organizations are re-examining whether past practice should continue to govern standard operating procedures. Government and airlines, for example, spring to mind. Last week, I saw further evidence of this in delivering a BPMN training class to one of the many Federal agencies involved in financial regulation. I was surprised to find that most in the class were experienced process modelers already. Many had prior BPMN experience, for some including BPMN-based BPM Suites. The processes of greatest interest concerned
Creating business process models that can be shared effectively across the business - and between business and IT - demands more than a digest of BPMN shapes and symbols. It requires a step-by-step methodology for going from zero to a complete process model. It also requires consistent application of a modeling style, so that the modeler's meaning is clear from the diagram itself. Author Bruce Silver explains not only the meaning and proper usage of the entire BPMN 2.0 palette, but calls out the working subset that you really need to know. He also reveals the hidden assumptions of core concepts left unexplained in the spec, the key to BPMN's deeper meaning.
“Scope” is an “everybody knows.” And that may be the biggest problem. Consider this example: After reviewing a presentation on a major initiative (tens to hundreds of millions of dollars), one senior executive proclaimed that with scope now established the need was to work specific areas. Another executive, reviewing the very same material, pointed out that it was, of course, clear that scope was still not understood!
Contributed by: Marvin Wurtzel, Principal Consultant, Marvin M. Wurtzel & Associates, Inc.
During the 1980s and 1990’s the use of flowcharts began to evolve. Next Business Process Management (BPM) came along to more formalize their use and combine their use with computer systems technology. Also in this timeframe, Six Sigma came into play as a means to improve processes by minimizing variability. Next, Lean six sigma evolved as a further means of reducing waste in processes.
McKesson’s Corporate Information Technology organization has embarked on a multi-year journey to become a customer centric IT service provider. In this session Kai will focus on his IT organization’s Service Delivery Model (SDM), which describes a tactical approach to development of services with its roots in ITIL.
The deployment of BPM suites are delivering the departmental productivity gains expected. Broader adoption however, hinges on gaining a consensus around a vision, crafting a roadmap, and embracing enabling frameworks. During this session, a foundation is laid for pursuing an integrated business framework to accelerate broader BPM adoption.
With approximately $33 billion in assets, Con Edison is one of the nation’s largest investor-owned energy companies serving the New York metropolitan area.
With approximately $33 billion in assets, Con Edison is one of the nation’s largest investor-owned energy companies serving the New York metropolitan area. Today Con Edison is in the process of developing a world-class business process improvement center of excellence to drive everything from building basic process model repositories to leading large-scale, cross-organizational process reengineering initiatives.
The biggest challenge with starting a process improvement initiative lies in understanding existing processes and knowing where to start. The traditional approach involves significant investment in time and resources to map out processes the outcome of which is often delayed and inaccurate. Read how Fujitsu's Automated Process Discovery Service helps companies:
If you are an architect responsible for a service-oriented architecture (SOA) in an enterprise, you face many challenges. Whether intended or not, the architecture you create defines the structure of your enterprise at many different levels, from business processes down to data storage. It defines the boundaries between organizational units as well as between business systems. Your architecture must go beyond defining services and provide practical solutions for a host of complex distributed system design problems, from orchestrating business processes to ensuring business continuity.
