As work piles up in our inboxes and on our desks, the question should occur — what important issues am I missing? It is an interesting fact that a high percentage of our critical work and the data we use to make decisions are still outside the operations systems we have — ERP, accounting, modeling and decision support. For many, the argument has been that codifying processes makes them rigid. This may certainly be true, but some process gaps are very costly, and in the fields of finance or import/export, they may be illegal. For example, a customer cancels an order with you, but you don’t cancel the order to the supplier. Or critical information about a patient’s allergies doesn’t get updated in the patient record. Or more shockingly, as I heard at a recent event, “ — not all trades were closing each night.” This was stated as being a small problem. As the audience gasped, the speaker said, “That is, technically.”
As the level of connection points, trading partners, channels, and compliance and regulations increases, companies have more ‘digital to-dos.’ Also, the increased focus on risk management brings up uncomfortable questions: Who is responsible for this process? Do we have it documented? Do we have the correct up-to-date data, contacts, etc. associated with the management of this process?
To a great degree, applications solutions providers have the business process management (BPM) tools within their applications. But what happens when we have multiple integration points, within or beyond the enterprise, that are not covered by the application? There are many industries that still have mostly their own in-house-developed software or a portfolio of many applications purchased one by one. Examples are transportation, healthcare, education and financial services.
BPM: Two Approaches — Custom vs. Customary
In practice, many firms have very enterprise-specific ways of doing things. There are unique processes and approaches due to the complexity of the business, and these processes need to be codified or automated. In practice, these become custom BPM projects. We usually see these used within an enterprise.
Customary practices provide the opportunity for reuse. This allows for more configurable or mappable implementations. We usually see these on the web between enterprises.
In a session lead by IBM’s BPM team, they walked us through many examples of custom BPM by industry — from healthcare to supply chain.1 They pointed out a few critical aspects to doing these projects:
- BPM teams are more successful when led by business people rather than IT. They understand the nuances of the processes, and what has to happen and why. It harkens to the business analyst — the person who may be the go-between for the IT department and the business. These teams generally need to be cross-functional in nature.
- Streamlining and improving go hand-in-hand with these types of projects.
Hubspan and firms like BabbleWare2 employ the reuse approach. Hubspan is workflow and Babbleware is a configurable task-level app that can be connected to workflows for feeds from enterprise systems.
From the workflow perspective, these are valuable in areas like channel management, financial services, and of course, supply chain where there are many agreed to, and often, standardized practices. They are beyond the scope of EDI, which is a transaction-based messaging system designed to feed directly into orders, payments, confirmations and such. The extended value here is for challenges such as community development — a multi-party process. This is not just about broadcasting announcements, but also ensuring the closed loop process with acknowledgement and confirmation.
Tasks from picking, to kitting, printing, kanban/pull, and many more can be implemented by the cross-functional team, in rapid fire, through their innovative implementation process.
Although Hubspan and BabbleWare fill out different areas of the white space not covered by other applications, they both focus on trading-partner activities like integration between a brand company, its distributors, and contract manufacturers. These value chain partners have a goal to operate seamlessly; yet each of these enterprises has their own systems portfolios. Hence, the partners need ways to share a variety of interactions in demand and supply activities. (The PO and EDI are often not used in these trading partner processes since there is already agreement about capacity; inventory goals {possibly with a blanket PO}; and distribution volume and schedule agreements.)
Why Do I Need This?
In fact, people are not that good at scaling — or remembering. Complex business processes, document sharing, scheduling and agreements — all secured, documented, and auditable — are required in many businesses. As businesses change, often the systems we have invested in don’t keep up with these changes. They may be inflexible. They may not have the data model or data fields we need to support the changing business. They may not have the necessary automated integration to the end-points and our trading partners.
We may not be ready (or have the power to) rip and replace. However, we can integrate the islands, and, more importantly, the people and the information and decisions they need to share.
_____________________________________
1 IBM’s product is Blueworks Live.– Return to article text above
2 Hubspan’s product is called WebSpan ; BabbleWare’s case studies can be viewed on SlideShare, here.– Return to article text above
To view other articles from this issue of the brief, click here.