IDS Scheer Partners with Systar to Launch New Process Event Monitoring Solution
IDS Scheer, the leading provider of solutions for business process excellence, today announced a partnership agreement with Systar (Euronext Paris: SAR) (ISIN: FR0000052854), the leading provider of Business Activity Monitoring (BAM) solutions. Under the agreement, IDS Scheer will embed Systar’s core technology to provide customers with real-time business event monitoring. The new offering, ARIS Process Event Monitor, will provide companies with real-time monitoring to manage exceptions and risks within business processes.ARIS Process Event Monitor will provide current process-relevant information and enable companies to react immediately to critical events. Rule-based alerts, notifications and actions intelligently identify critical situations based on automated tracking of on-going processes fed by sophisticated adapters that capture, filter and aggregate events.
This won't be 'unveiled' until March 2007 at the CeBIT conference...maybe we'll get a sneak-peak at ProcessWorld in February.
The growth of the business analyst (my current focus) is just one of 7 Channelweb Business and Tech Trends for 2007. Other interesting trends include the need to capture retiring knowledge (and how blog and wikis can..and NOT.. be deployed to help) and BI real-time help with performance management.
A current challenge to integrate business process models developed in ARIS and implemented in BEA Aqualogic (or any combo BP modeling and BP implementation platforms) may benefit from understanding Oracle's Business Process Outlines approach, as explained by Bruce at the BPMS Watch blog. Bruce tries to explain how Oracle's Business Process Outline attempts to keep Business Process Models designed in their Business Process Analysis (BPA) suite (their implementation of the IDS-Scheer ARIS tool) in sync with what I call Implementation models in their SOA Suite.
"...a problem with BPEL in BPM has always been keeping the executable design in sync with the business analyst’s model once the developer has taken a whack at it — the notorious roundtripping problem. Oracle has solved that here with the Business Process Outline - a model that sits in between BPA (ARIS) and BPEL, with unambiguous mappings to both, and intelligible to business as well as IT."
I wonder if some of this approach will flow back into the ARIS product and be generic enough for other BPM implementation platforms to adopt.
EDS' Next Big Thing Blog : BPDM is Key Step Forward for Business Process Modeling and SOA.
Sometimes I read some of these articles on the various levels of standards in the Business Process Management realm and I feel like Jessica Simpson in that ever-rotating High Definition TV ad. But this standard is being discussed by the same body in charge of the Business Process Modeling Notation, OMG, so I must want it.
I believe that utilizing existing frameworks, like APQC PCF, SCOR, etc., and reusing existing process models can alleviate some of the The Problems With Modeling that Robert McIlree writes about on his blog. As business architects, we definitely need to understand the goals and methodology of the projects we are working on and attempt to build architecture models as they are needed to support what the project is delivering right now. A high-level to low-level approach seems to support this, delivering models that help to define scope and early project deliverables like plans and functional hierarchies of processes and roles and then build on these with more detail, like swim-lane diagrams and organizational charts. I'm surely just getting my feet wet with this approach, but am hoping codify some of it so that others in my organization can architect and model in this value-added way.
Although I'm not a fan of the Web 2.0 hype-title, I just call it the web, ebizQ blogger Sandy Kemsley (who it looks like will be at ARIS ProcessWorld 2007 in February) ties in some of a bloggers favorite tasks (tagging, and RSS syndication) in her 2006 Wrap-up / 2007 Look-forward post:
"There are two more Web 2.0 characteristics that I think we're going to start seeing in BPM in 2007: tagging and process syndication. Tagging would allow anyone to add freeform keywords to a process instance (for example, one that required special handling) to make it easier to find that instance in the future by searching on the keywords. Process event syndication would allow internal and external process participants to "subscribe" to a process, and feed that process' events into a standard feed reader in order to monitor the process, thereby improving visibility into the process through the use of existing feed technologies such as RSS (Really Simple Syndication).
It truly will be interesting to see how these blogging-popularized knowledge ellicitation (tagging) and knowledge sharing (syndication via RSS) techniques and tools integrate in with BPM product offerings.
I cringe and second guess our ARIS decision everytime I read, like in this BPM 2006 Wrap-up about the further BP industry adoption of Business Process Modeling Notation (BPMN) standard:
2006 was the year that the Business Process Modeling Notation (BPMN), a notational standard for the graphical representation of process models, went mainstream. Version 2.0 of the standard was released, and every major BPM vendor is providing some way for their users to make use of the BPMN standard, whether it's through a third-party modeling tool or directly in their own process modelers.
IDS-Scheer has been slow to provide robust BPMN support in the ARIS tool, mostly due to the fact that most ARIS functionality is built around their proprietary Event-driven Process Chain (EPC) notation. I questioned their CTO at ProcessWorld 2006 about this and the answer was that most of their current clients weren't asking for BPMN support because they already were way down the road with the EPC notation. I have to admit I've grown to like the structure and workflow-supporting emphasis on events (key milestones in the life-cycle of key corporate information and situations...i.e.: Contract Opened, Contract Modified, Fiscal Calendar Begins) that EPC enforces, but I equally see the fact that the process flows that most business people know how to do themselves more closely resemble the BPMN standard.
I will put together a post showing some of the major places I see differences in the process flow s I get from SMEs and how they translate into EPC format.
The Open Process Handbook Initiative Authoring Guidelines (in the 'Specifics of an entry' section) provides some really good tips and principles to use when describing business process activities. The document's 'General method of creating entries' section also covers the different options for doing process decomposition which enforces development of an easy-to-complex hierarchy of processes (aids in communication) and reuse of process assets...albeit in the context of OPHI's Process Handbook (but they describe a general method that could just as well be used when developing processes in the context of the APQC's PCF, which I would like to see us use).
One goal I have for moving business process design forward is for all business process modelers to utilize some common standards when describing business processes. When it comes to business process modeling notation, my organization has adopted the ERP de-facto standard Event-driven Process Chain (EPC), which is fully implemented by it's developer, IDS-Scheer, in their business process management tool ARIS. EPC templates and shapes are also available in MS Visio 2003 Professional. But that only gives us a graphical notation to use...it doesn't set the standards for how we name the processes and elementary activities (aka functions or work steps) that get drawn in the tool. That is still a decision of the business process analysts and/or subject matter experts designing the processes.
Does an IT Service Catalog equate to a process framework for IT that can be used to organize the processes of an IT organization? In reading The Boris Files - Secrets of Successful CIOs: Best Practices for Service Catalog Design, it seems like it is, but I'm in dire need of some confirmation of this, so I can bring it to IT folks that are beginning to document their business processes and need a structure for doing this.
Here's an interesting graphic from the article that shows what I think are different branches of the IT Services tree (although the reverse-stairstep nature suggests a hierarchy itself).

I'm helping to organize a process framework for my business, to enable us to all speak a common language, take advantage of standard benchmarking data, and just be organized. One framework that I'm looking at using (mostly because I haven't found another one as complete) is the APQC Process Classification Framework. The PCF has a branch called 7.0 Manage Information Technology and Knowledge.
But there is lots of talk in our IT organization about aligning along IT Services and ITIL. Some groups in IT are starting to document their processes, which I believe equate to ITIL Services .
The big question for me is should we swap out the APQC PCF 7.0 section for something that is more ITIL standard, like this concept of an IT Service Catalog? Is there a hierarchy or outline for IT Services based on ITIL that presents itself more like the APQC PCF outline?
SAP Developer Network Blogs - BPMN or EPC? provides an overview of both business process modeling languages, with the author showing his bias (correct IMHO) with the more detailed description of BPMN. BPMN is closer to what regular business people know as flow charts, so I think it's much more easily adopted. The support for BPMN in ARIS is very limited, so much so that it can't really be used if you are going to take advantage of the full capabilities in ARIS (automatic relationships between objects, like roles and responsibilities for instance, or simulation). This is a shame. But if you are just adopting standards for modeling in your organization, it doesn't really matter what notation that you use as long as you standardize on one and educate the business through examples, training, etc. Once they start seeing them, they will understand how to read and, eventually write them, themselves.
McDonalds execs are blogging and it's not just the CxOs. And BlogWrite is Lovin' It (or at least Writin' It)! A recent discussion on the corporate blogging topic only made me more convinced that retaining the Personal, Unique voice of the individual is key and what sets apart blogging and it's related New syndication vehicles (RSS, podcast, etc.) tools for Knowledge Management / Collaboration / Communication from something that's just New.
Debbie Weil and BlogWrite for CEOs illustrates that individual voice well and is a great new find for me, getting into the in and outs of corporate blogging...and really getting Into It...dig the excitement of her first podcast (nothing mini about it Deb).
And in the practice of sharing that Debbie leads the way with, I use http://Audioblog.com for Live phone conversation / interview recording and auto-posting to various VO weblogs and http://Flickr.com/photos/vo for Live picture / image storage and auto-posting via cameraphone (and digi-cam)...fun tools. I also use http://Streamload.com/outlawv for hosting other audio / video files (made available via podcast RSS enclosures in some cases), mostly MP3s of TNJT interviews...like last night's killer chat with Reid Anderson of The Bad Plus (not quite up yet)...but Streamload download costs are getting expensive as the interviews get a bit popular...so I think I'll be looking distribution via BitTorrent soon (although I hate to think about having folks scale that tech wall just to get downloadable versions of the interviews...ugh). I'd like to get into the Skype and PC / Mac mobile recording set-up too, so it's good to hear Debbie's experience with it.
Keep Lovin' It Deb!! VO
Beyond Monoculture | Doc Searls' IT Garage: When any culture focuses it's hero worship on one entity, as the blogosphere has done with Google, then undesireable mutations, like incestuous blog spam, will no doubt result. Diversify!
Line56.com: Solving the Process Puzzle
Comment from IDS-Scheer founder Dr. August-Wilhelm Scheer on the growing importance of business process, even to the point of moving your Chief Information Officer to Chief Process Officer.
"The CIO should be responsible not only for the technological infrastructure but also for the content," says Scheer. "The CIO should be responsible for what people are doing with the technology and how they can get benefits." In other words, the CIO needs to think about crafting and applying reusability principles that tie right into process management wherever it is deployed.Sadly, though, the brief tenure of most CIOs makes it difficult for them to get past high-profile technology deployments and into the process layer. Scheer admits that, until CIOs are not associated primarily with, and switched out as frequently as, 'their' technology, it'll be difficult to get them to transition to a CPO-like function.
This is an interesting position. Gartner/MetaGroup has recommended moving the Enterprise Architecture group which would include the Business Process Architecture, under the Chief Strategy Officer to provide that business focus to IT efforts.
The identification of Roles and Responsibilities for a business process, a very critical step in any process improvement methodology, begins early on in the Define phase of the Six Sigma methodology when the Project Charter is being drafted and the Project Stakeholders are being identified. And it carries all the way through to the concluding Control Phase, when process documentation and other assets needed to Control (Monitor) the process are being developed and diseminated into the organization. Being able to see where you can postitively impact the end of a process improvement project with some smart work up from seems like something worth writing down.
It seems like a good technique to use when doing the early brainstorming of Project Stakeholders would be to categorize them into Process Stakeholders and Project Stakeholders. Process Stakeholders would be the list of 'Roles' that are involved in the process, while Project Stakeholder mostly would have a stake in the successful completion and tracking of the process management / improvement project. At this point, validate these Roles against the enterprise list of Roles to make sure all is copious with your architecture...if there are any descrepancies or changes that need to be made in these enterprise Roles or their definitions, see if this will be something the project itself will further define or whether you can suggest an immediate 'quick win' to update the enterprise Role list.
Back into our Define phase, the list of Process Stakeholders (Roles) would then be the 'seed' of brainstorming on the process' Suppliers and Customers, which are critical elements of the first process detail diagram in Six Sigma, the SIPOC. I would think that the SIPOC would contain all those Process Stakeholders in either or both Supplier / Customer columns. Any additional Roles in the process that were discovered during SIPOC development would be added to both the SIPOC and to an updated Project Charter's Stakeholder list.
Futher detailing of sub-process maps below the SIPOC level would then begin to associate the more detailed process activities to one of the Supplier / Customer Roles, building the list of the Responsibilities for each of the Roles. And there you have it...Roles & Responsibilities...start to finish...spend time up front!
I was looking up General Dynamics Six Sigma for some very covert reasons...hehe...but stumbled onto this GD Advanced Information Systems Powerpoint "A Process Framework for Enterprise-wide Integration" which illuminated another looming issue for someone moving their enterprise to a Process Driven Methodology (utilizing Six Sigma or any other process methodology)...Process Asset Library.
I'm thinking that in the same manner that we need to plan measurement dashboards and metric repositories, we need to enable the actual running of those processes by the process owners and service providers. They will all need access to the diagrams, procedures, forms, checksheets, etc. need to complete the process and they will need to access this information in a way that integrates with the actual performance of the service.
I'm thinking this needs to be integrated tightly with the dashboards displaying the status and trends of the process...have everybody from management to process implementor using the same Process Portal.
To see how GD went from integrating multiple process improvement programs (I think SOX-compliance would be a good one to include on slide 8's bullseye diagram) to a Process Asset library providing access to process documents from the highest value stream to the lowest function and checksheet, check out the presentation, especially starting at Slide 10, seeing how the Value Chain is represented in the on-line Process Portal, enabling drill down to the level of process information needed. Cool.
The Blind Men and the Elephant: Cute poem came up today in reading a book explaining what an enterprise architecture looks like to the enterprise...many different things...and no one really sees what it is.
VARBusiness reports on a recent Gartner Symposium led by Neil MacDonald titled "The End of the IT Department" where the following prognostication was made,
"By 2015, 90 percent of the employees in 2004 Global 1000 IT departments will have been automated, outsourced or absorbed by other business units, according to Gartner research. In addition, by 2015, 30 percent of the Global 1000 will no longer carry a CIO position. "
Kind of scary? Or kind of exciting?! If you've been evolving (or sliding head-first) toward a more business process view of your IT job, you're moving in the right direction...
"As IT departments change, there will also be a need for new roles within IT organizations and for the parties that cater to these organizations. MacDonald sees the need for a next-generation sort of "business-process architect," a business systems analyst at the process level to orchestrate the flow of information. He also detailed the role of what he called "an enterprise business-process architect," who can oversee business architecture and business systems engineering -- something for solution providers and resellers to consider for their future IT roles as well.Others also see the need for the role of a business-process architect in IT. During a keynote CIO panel on Tuesday, several leading CIOs assembled for the event said they, too, see the need for such a position inside corporate IT departments. When asked about new roles in the information services area, Tony Cicco, CIO for the General Accounting Office (GAO), who oversees 13 IT teams that address the needs of different parts of the government, said he saw the role of an enterprise architect as a logical step. Cicco also saw the importance of a customer relationship group within IT to service internal clients or employee users.
"
I was also happy to find some very relevant information to building out the business process technology stack that I need to find best practices and tools to enable in my new next assignment,
"He sees this being achieved through business processes in XML or Web services, business process management suites and business rule engines, such as workflow, identity and access management. "
Improvise and remain nimble as the end draws near!
As IT departments change, there will also be a need for new roles within IT organizations and for the parties that cater to these organizations. MacDonald sees the need for a next-generation sort of
A Federal Computer Week (FCW) article from April, 2004, "This year's model: Business process" discusses the different approaches being taken for Business Process Modeling for U.S. Government agencies, with the new kid on the block, Business Process Modeling Notation (BPMN) getting more than just a nod,
"Those getting back into business process modeling will find an old standby and newer methods. Integrated Computer-aided Manufacturing Definition (IDEF) was the approach of choice in the 1990s and remains the only one compliant with Federal Information Processing Standards (FIPS).But joining IDEF now are two other techniques: Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN).
UML comes from the object-oriented software design world and has been pressed into process modeling chores. Meanwhile, BPMN is an emerging approach that is gaining traction among software tool vendors. It promises to do what previous approaches have failed to accomplish: integrate systems development from the business process model to actual code generation."
It looks like BPMN is really making some inroads into the market, replacing IDEF. A year or two ago, it seemed like UML extensions for business process would be the holy grail, because UML was already being accepted as a standard for modeling (and then to db schema / code framework generation) on the software engineering side of the architecture (as opposed to the business engineering side...my current concern), but even from my standpoint, UML diagrams don't seem very user-oriented. And, for what it's worth, IMHO, the real mapping to code will now be from BPMN to the code that's going to run closest to the business side of the house, Business Process Execution Language, the scripting language for the next generation business software platform, Business Process Management.
One additional quote about the Department of Homeland Security's transformation office tools helps point out a need to supplement modeling tools with a robust requirements / rules documentation tools,
"The transformation office uses Telelogic AB's Dynamic Object-Oriented Requirements System to assess its requirements and Popkin Software's System Architect, which supports BPMN, for architectural development. "
Business alignment with information technology is a subject that Enterprise Architects should be thinking about daily (even those of us fighting for our rightful place in the flow of enterprise strategic planning info). Maybe I've been indoctrinated too much into the MetaGroup way of thinking, but what I read most among technology people approaching Enterprise Architecture is a scope much smaller than the Enterprise. It seems like it's much closer to the IT Enterprise, focused on a structured, well documented, and reusable technology and application architecture. In those cases, the strategic direction of the business, which should indicate where IT resources should be deployed, seems to get left off the list. And not there's anything wrong with that...it's all a matter of EA scope...but I think it's something different than Enterprise Architecture, or 'holistic' Enterprise Architecture as I've heard it.
An illustration is the Business Aligned post by CityArchitect over at the ITToolbox, where City' gives some scope-increasing techniques to become 'business-aligned' with this as his highest level
"Technique number three in this great alignment strategy is to map Applications to the Business Processes that they automate; we can then relate real Business Transactions to transaction flow in our Applications, and map our Applications to their Host servers and, coupled with Business Systems Management techniques, we can relate System Health, Problem Management and Risk right up to the Business Process. "
I'd have to add a #4 that said that Application development (now called IT Portfolio Management, I believe) that was undertaken based on the strategic plans of the enterprise would be at least a higher level of 'Business-Aligned IT'. It's at least something to talk about.
One more comment on a part of City's very cool post dealing with ever increasing IT Portfolio (which he calls 'base of technology'),
"The reason that this base of technology goes on increasing, is that we don't seem to turn anything off; we don't retire the old systems and technologies. More stuff, more people, more cost, more maintenance."I'd add that another reason for the increasing amount of stuff is that there are ever-increasing 'layers' of Things on top of what we already have, like Portals on-top of our webservers and app-servers or Business Process Managers on top of our exiting EAI or workflow technologies. The 'get rid of legacy' mantra of the past seems to now swung over to 'integrate the legacy (with some new stuff that will soon become legacy)'!
Keep blogging on, City!
Process Wave: Move your mouse over the top ProcessWave graphic on their site. Rad dude!
OK. Back to work.
Metastorm and SAIC Strengthen Partnership with New BPM Business Practice
SAIC has assembled a comprehensive "business process fusion" platform that incorporates Metastorm e-Work as the BPM component. An Enterprise Application Integration (EAI) solution and a Business Intelligence (BI) solution will also be included in the new offering. With a horizontal focus on BPM across multiple program areas, SAIC's new practice will initially focus on operational risk management and supply chain operations. SAIC will leverage the domain expertise developed as part of its already successful Metastorm BPM deployments in the Department of Defense, federal intelligence organizations, and the civilian government to deliver both applications and consulting services that will help organizations achieve business process fusion across legacy and emerging Enterprise Resource Planning (ERP) environments.
BEA Systems and IBM, meanwhile, have published a white paper on BPELJ, which enables Java and BPEL to be used together to build business process applications. Available at http://dev2dev.bea.com/technologies/bpel/index.jsp, the white paper outlines how BPELJ works, according to BEA.Web Services Business Process Execution Language, commonly referred to as BPEL, was proposed by IBM, Microsoft and BEA as a mechanism for orchestrating business processes in Web services environments. It currently is under jurisdiction of OASIS.
BPELJ has been submitted a proposed direction for Java Specification Request (JSR) 207, through the Java Community Process, according to BEA. JSR 207 is officially called Process Definition for Java, and is to feature an annotated Java syntax and APIs for programming business processes in Java.
Interesting in that I was under the impression that BPEL was a specification for a platform-independant, textual language describing a Business Process. So what's up with a language specific (Java) of BPEL?
Reading the link above, it seems like BPELJ will extend BPEL to not only orchestrate web services to complete Business Processes, but will allow orchestration of process steps that may not necessarily be available (or desired) via a web service because the resources needed are local and more efficiently accessed with local means. The articles uses files, queues, EJBs as examples of these local services that might be marshalled for a process but not necessarily available via web services. BPELJ will allow Java services to play in the BPEL game. But not without some cost in the portability of your BPEL code, as I read this quote from the article,
"BPELJ is a combination of BPEL with Java that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best. Since BPELJ is implemented via extensions to the BPEL language, any BPEL process is also a valid, executable BPELJ process. By standardizing these extensions, BEA and IBM are working to ensure that real world automated business processes will be truly portable and interoperable across the J2EE platform."
I think the key here is "...across the J2EE platform". If you code the BPELJ extensions, then your BPEL may not be portable to other BPM platforms. I'm not sure that this is the right answer to pulling in local, non web-serviced, resources into business processes.