|
|
Only in the tech world could we be in June passionately arguing about "top down" and "bottom up" and not be in a convertible drving up PCH to Zuma with a cooler full of Pacificas and limes in the trunk. Well, to return to the summers of your youth and live the dream of BPM, now's the time to download this 8-track podcast., set aside Danielle Steele and for the next 22 minutes listen to ebizQ's Gian Tratta interview me about why and how to implement top-down BPM strategy.
"Our view is that business process management is a business function and it is something that should be pervasive to your organization. If you're really going to start viewing your company through the prism of process, this requires top-down commitment."
I know that's pretty steamy but if you can handle it, there's more where that came from. Enjoy...
Technorati Tags: Blueprint, Gian Trotta, ebizQ
In two terrific blog posts, CIO of the services arm of British Telecom JP Rangaswami blogs about visibility and openness as the heart of process excellence. He talks about documenting the reality of your company - and of your customers' interactions with it - and leaving behind the failed "process" approach of ERP, CRM, SCM (and I'd add EAI, so-called "integration-centric BPM" to the list).
Bravo, JP!
Where you didn't go in the posts, but I suspect have in your head, is whether we should open-source process frameworks and KPIs for companies. While the dirty details of implementation (at, say, the BPMN level and below) are not something most companies would want to share (not because of of competitive advantage but because of competitive disadvantage, disclosing weaknesses in process that could be competitively exploited), I think that higher level process and strategy maps would be valuable to standardize: a tangible Zachman for your industry for example, along with the specific metrics and KPIs that you are expected to achieve. Wall Street is almost certainly already judging you on these (the higher level ones anyway, which have implicit, just not explicit ties to the lower-level ones). Why not just agree on them? In the same way that every company is currently reinventing the wheel with respect to non-differentiating technology (how many redundant WebSphere administrators are there in the world?), companies are also wasting their collective time on drawing the same high level process maps and agreeing the KPIs that are linked to them.
Excellent companies in _any_ industry are process-excellent. The KPIs of these processes are almost always known (most truly excellent companies share them, even with competitors, for they are not "insecure," another aspect of JP's posts I am glad he discusses). Toyota is famous for sharing its methods and results with competitors, for example. These companies compete on their ability to innovate and improve, not on some static state of today's process (of course, certain technical processes, like painting methods, are secret).
Visibility, transparency and a willingness to change (I call this culture) are the key elements of BPM, not execution and workflow. Those are simply two of the many artifacts of where you are at any given point in time on the Process-Driven journey. Great BPM technology should encourage the visibility, transparency and cultural change parts of your journey to become process-excellent... we've already got enough technology that simply encourage how to build workflows.
So read JP's posts (here and here). And for a similar set of thoughts, as well as the beginnings of how to go about achieving this process excellence, click on the picture of my forthcoming book, Process Driven, and you can get a copy of Chapter One, where I discuss shining a light on your company, and the four pillars of BPM.
ps = And for those of us north of the equator, happy first day of spring, when the sun shines its light for longer periods of time on the state of our lawns and gardens. Driven by guilt or desire, we improve them constantly. Then winter's rest, and then they reappear, a little better, the next year. We're in our sixth year at our current place, and each year the garden is in better shape. Maybe it can be springtime at your company, too; it just requires a little sunlight and a willingness to improve.
Technorati Tags: Visibility
I just got off an eBizQ panel discussion hosted by Sandy Kemsley. What a ball.. no slides, just good, topical conversation. Speaking of the conversation....
The panel also consisted of Phil Larson of Appian, Ismael Ghalimi of Intalio. The topic was "BPM and Enterprise 2.0" and we discussed, among other things, what the technologies of (so-called) Web 2.0 meant to the enterprise. A lot of people are looking for a fundamental shift in the BPM world, but I don't think they get it at all. Of course these technologies will make a difference in enterprise applications and mission critical processes, but I don't think that's their initial highest and best use.
Process execution (aka workflow) is not the interesting part of BPM and therefore, process execution from "Web 2.0-like" tools isn't the most interesting use of these new capabilities. Not to get all Cluetrain on you, but the main thing these new technologies give us is a new way to communicate, not a new way to integrate!
Behind-the-firewall BPM is about giving visibility into your core processes, and giving you a more flexible way to implement improvements to those processes. Visibility and improvement are non-trivial things. They require thoughtful implementations (not "zero-code" implementations) and they require top-down guidance. If you don't have leadership at the very top of the tree behind you, then you just aren't doing BPM. But how do you structure that top-down view? How do those leaders tie process to high level goals - the goals that if you hit them you'll still be in business and thriving in five years' time? How do you quickly decompose those processes that make strategic impact and determine which ones have the highest impact? And, finally, how do you know when to hand off those decomposed process "chunks" into a robust behind-the-firewall BPMS that offers a shared model with the higher level views as well as the hard core capabilities of an enterprise class platform?
What I've found over and over is that there's no good way to have the top-down conversation! And it turns out that this is exactly what the new SaaS technologies allow!
So my answer to the "what is Enterprise 2.0 and how does it tie to BPM" question? Here you go:
The key stumbling block to real BPM has been the inability to have a structured, high-bandwidth conversation from the top-down about what the goals of the company are and the related processes that impact those goals. Enterprise 2.0 enables that conversation with new tooling that combines the best of social software with a shared process model accessible to and from the behind-the-firewall implementation BPMS.
Enterprise 2.0 is here, but it's not a regurgitation of the old execution-centered (workflow-centered) BPMS's of the past. It's an extension of the process execution and control systems into new areas of the enterprise, enabling new conversations, that dramatically alter the process life-cycle within a company. And then it's the tight coupling of the internet-based capabilities with the behind-the-firewall capabilities so that a new, more flexible breed of enterprise systems evolve.
Agility comes from being able to respond to strategic changes quickly, not the ability to change a random workflow. Enterprise 2.0 enables this - but not by recycling concepts of execution and web services. We're entering a new era, we're not going back to the '80's... this isn't client-server, and it's not just another set of Excel or Access craziness. It's about empowering the individual but in directed ways that (a) contribute to the company's success and (b) utilize scarce resources to their fullest.
Technorati Tags: 21st Century Process, BPM 2.0, Enterprise 2.0, Web 2.0
Much is made about how BPM is “going to change the way businesses are run” by having “the business” become involved in the development, optimization and evolution of these process applications. This is a cause for consternation by experienced technologists who are [understandably] worried about having the business “run amok” with programming tools. There are enough shoddy applications that contribute to IT’s maintenance nightmare; we don’t need more of them, we need fewer. Maybe, then, “don’t let the business harm the business” should be included in the hypocratic oath of BPM.
On the other hand, the business is clamoring for tools. Tools to help them take control of their own business processes. Tools to help them emerge from under the “iron boot” of unresponsive IT departments. Tools to let them be productive in groups - like Microsoft Office has allowed them to be productive individually. Prospects tell me that “our customers are making demands on us - we have to move faster! We know technology can help us, but it takes so long to do anything, we question its value.”
So here's the dilemma: on one hand, IT needs to be more agile to respond to the marketplace at a faster pace than ever, and on the other hand, much of the clumsiness is a result of "just doing something" which resulted in all these silo'd systems (and people, too).
It's the irony of our times that the very systems that have allowed business to scale have become so complex they are the obstacle to scaling further, faster.
How do we get the power of people doing business in agile, de-centralized ways, baked into our technology? Or, stated differently, how do we embed technology so deeply into the business, that business programmers can take over without doing harm to themselves?
What can we agree on?
First, let’s find some common ground. To do this, I’d like to look, say, 30 years into the future and propose that:
• Business people will be smarter about technology than they are today.
• Tools will be easier-to-use than they are today.
I don’t think those are too controversial. That's certainly been true over the past 30 years. If you agree, then you'd probably also agree that at any point along that "30-year path", there are incremental improvements.
People getting smarter: It's difficult to plan for the increased savviness of the work force, but it happens. It's usually the result of fundamental shifts in technology. Whether it's the Walkman or the web, everyday people get smarter about using technology in their daily lives. And while we can't really affect the timing of this, technical literacy rises over time and it is what it is (or will be). So let's simply assume a line that depicts the rising technical capabilities of line-of-business people over time.
Tools getting easier: As to the second assertion – that tools will be easier-to-use – hopefully we can agree that the state of these tools is going to get a lot better. Bill Joy, in his famous speech to The Commonwealth Club a few years ago, pointed out that the difference in energy between a matchhead and an atomic bomb is about 10**12 and that with the advance of hardware and software technology, that’s about the power differential of personal computing between 2000 and 2030. The impact this will have on user experience and accessibility will be staggering. By then, we'll be negotiating contracts via Second (or Third or Fourth) Life, directly with our customer's avatar and the result of the negotiation will be represented in the process model, a contract will be generated, triggers based on the agreed SLAs will be established and a choreography will be instantiated. And you won't have to know a damn thing about "process"...
So tools get much easier to use, over time, as this chart shows:
This trend started with the first personal computers and VisiCalc, through to today's Microsoft Excel and Google Spreadsheets; from WordPerfect to Microsoft Word 2007. Today's business is "programmed" by end users in ways largely unimagined 30 years ago. This steady advance in usability will continue, unabated.
This trend is now moving from personal productivity applications to enterprise applications, and will continue until the very business is “programmed” by business people, so that the business’s processes – like today’s documents – are directly manipulated by them. It is simply a matter of time. Is it 30 years? 10 years? How much will the line move over, say, the next 36 months?
Business Programming will occur. Lombardi’s mission is to accelerate that capability for our customers. If you believe that pushing the levers of agility closer and closer to its users (the business), then every advance in tools accelerates the benefits that result from business programming, as the charts below show.
 There is a role for IT
Of course, there is and will forever be a role for technologists – people inside the organization who focus on the hard bits of technology. In the same way that increasing computer power enables ease-of-use, so it will also enable complexity (and evil, according to Bill Joy, but that's for another post...).
The pace of change of networking technology will continue to increase and, for large organizations, there will be an inherent advantage to having technologists on the leading edge. Technology - in whatever form - will be a competitive differentiator for many companies, at those edges where innovation is occurring.
At the same time, more configurable technology will be used by a wider audience. Look, for example, at cell phones. They are easier to use than ever, and more people use them, but there’s a lot of technologists at phone companies keeping the dial tone on. What we’ve done with cell phones is push out the “business use” of the infrastructure to simple devices at the edge of the network – and hidden the complexity of the network from the user of those simple devices. Those simple devices aren't only doing simplistic things, they are just simple to operate, and operate with very evolved interfaces into the core network which, at, say, Sprint vs. Cingular is different, and people with special technical skills and experience are required by each of those companies.
I was at one customer recently who has an investment in their core systems which measures in the 10's, if not 100's, of billions of dollars. That infrastructure isn't going away in my lifetime! Yet, their need for agility and the ability to compete using those systems - indeed, leveraging those systems as assets and not liabilities - is the key to profiting in this century.
Hiding this complexity, enabling process control and visibility, and working in partnership to foster change is the issue. And in order to do this, it's going to take all the technical and business expertise available, focused on the important problems in your company. If there's competency in the business, let's grab it!
What does this mean?
So in order to facilitate the move to business programming, BPM technologies need to strongly evolve in the following areas:
- Business Strategy: Massively easier-to-access tooling, and easier-to-use UIs for business users, to get started quicker, without IT involvement, and specific easy-to-understand ways to collaborate on "final mile" issues that require IT.
- Collaboration: Embrace the highly collaborative post-internet world, beyond simplistic ECM and into wiki’s; beyond simple, structured ad hoc routing and into sharing; beyond over the web and on the desktop to an access anywhere, anytime, well beyond the connected-only world of Web 2.0, and into the mobile world we live in.
- Modeling: A more expansive view of modeling the business, not simply modeling a process. Mixing modeling with process execution to a degree not seen before, recognizing that “simulation” and “historical data” must be mixed in order to truly model an organization; and moving models well beyond process diagramming and into living entities that are on a par with running processes… because modeling the business is a real-time, production effort and the asset – visibility – is more important than the assets of, say, ERP.
- Governance & Behavior: Better tracking of governance (maturity) and behavioral (motivation) models so that the enterprise competency of BPM can be grown, made visible, and incented.
- Infrastructure: Hardening the vertical communication touch points, but not the paths. Ways to control the interfaces into the legacy network must be provided so that business people can easily discover previously-used data, and also facilitate the collaboration between business and IT when new data requirements exist.
"If you aren't first, you're last"
BPM is the technology for these times because it's the only enterprise technology that embraces the technological "perfect storm" you are competing in: the convergence of highly distributable technologies, a highly connected world, and a new majority of users in the business who are capable and eager proto-technologists. And because it does it in a connected, heterogeneous way instead of being "rip and replace," it's a technology you can actually use from large business to small!
So next time you think about BPM, think for a moment about these trends and about what you want to enable over the next few years at your company. Business programming is coming, and like Ricky Bobby said, "If you aren't first, you're last." Whatever that means.
Technorati Tags: 21st Century Process
I received the following email the other day...
"My colleague and I have been having a running discussion about whether there’s a meaningful distinction between human-centric BPMS and integration-centric BPMS; and, if there is, whether it’s more likely to persist or to erode over time? I argue that that there are many fundamentally human-centric processes being executed in our company every day which have little to do with the ERP screens (etc.), and that these are most effectively managed in a much more agile, decentralized way than with enterprise modeling. My colleague says that 'processes are processes' and that if you model a system-to-system process or a human-to-human process it should all be the same. Since we have an EAI tool, why should we talk to other vendors?"
A General Theory of Process?
This is a healthy debate you're having. I'd like to deconstruct it a bit, though, because the way you've articulated it above is still flying a bit high level. It's hard to argue against a "general theory of process" in principle... it's just that in this case, you and your colleague are overloading the word "process" to mean two things.
Primarily, we need to understand the difference between process patterns and business processes. This is a distinction that industry pundits have inadvertently confused, and those vendors who advocate basing the world around their pipes or execution languages (e.g. an ESB or BPEL or XPDL) have intentionally blurred the differences.
A business process will inevitably follow a process pattern, but a process pattern is not, necessarily, a business process. Integration-centric approaches to BPM often try to confuse you and say, essentially, "you can draw a process pattern using a graphical notation, and you can draw a business process using a graphical notation, therefore executing a system-to-system process pattern must be the same as executing a human-facing business process."
But they are not the same thing. And more importantly, the real payoff isn't in executing a business process, it's in managing a business process. If executing a system-to-system process and managing a business process were the same thing, then all great programmers would be great managers, and all great managers would be great programmers. I mean, I've read all of Jack Welch's books but I don't get the impression he was a great developer...
Why aren't they the same thing? Well, probably 98% of the people in your company do not report to the CIO... they are "in the business." How do they work? What collaborations are required? How much of those collaborations should be explicitly coded, and how much should be left ad hoc? What about reporting, which is key for any human manager to do his or her job? What about tools to understand the decisions humans make? What about visibility into SLA's on activities that are left ad hoc?
Solving for the The 98% Case
Human-centric BPMSs are trying to get to the heart of how to depict and manage the work of those 98%. This is a very different problem than "graphically depicting a workflow and executing it programmatically." Those 98% are there to, essentially, add unstructured value to what they do! Therefore, the job of a BPMS is to (a) help identify the tasks where people don't add value and automate those away and (b) give visibility to the rest of their work so that priorities can be constantly monitored to make sure everyone is working on the right things.
No matter how efficient you get, you will always have 98% of your people "in the business." And the job of management is dealing with those people and making sure they are working on the right things at the right time. Managing a business process involves the coordination and prioritization of many types of activities, some structured, some ad hoc. The execution of the work flow is only a small piece of the puzzle!
Therefore, great "human-facing BPMS" is about centralized visibility in an inherently de-centralized "execution" world. Integration-centric BPMS's take the exact opposite viewpoint. They assume some centralized execution, and then offer very little in the way of reporting, simulation, and optimization. Their view, like rules engine vendors before them, believe the problem is one of automation! Human-centric vendors believe the issue is visibility.
The Methodology is Different
The differences in the path to optimization - the continuous improvement part of the BPM promise - is clear and stark as well. The business-facing vendors are moving more and more into business intelligence realms. I often talk about the goal of human-facing BPMS to be "enhancing the velocity of communication between the business and IT." If we do that then, in the same way as increasing the velocity of the money in an economy actually increases the money supply, we'll be able to increase the value of the process solutions.
Despite the marketing words, take a look at the implementation of optimization capabilities in the products. In order to improve something, you must understand it. And integration-centric tools don't really change the way business people can understand the process... therefore their optimization and improvement tools are simply IT-centric "see it's real easy to change" demoware.
Optimization starts with visibility into process performance. And from there, it requires many technological underpinnings to move the improvements into the real-world process. Look at the entire process-improvement lifecycle, starting with "how is my process meeting it's business objectives" and then move all the way to deploying some changes. You will see vast differences in how the business-centric vs integration-centric products handle this. Is the focus on the business process, or just the development process?
And the Architecture is Different, Too
Want to place a real big pothole along the path to BPM? Just require a specific IT-based technology to be implemented prior to the process being implemented. That's what the integration-centric vendors have done. They require you use their EAI or ESB as the conduit for information. We met with one large integration-centric vendor and they require the linkage between human activities to be their ESB! Agile, huh?
Business-centric approaches must be agnostic to the source. Your legacy environment is too complex to simplistically (and, by the way, profitable for the vendor) require a specific integration scheme. Even so-called "wall-to-wall <name your ERP> shops" aren't, really "wall-to-wall."
And further, the relevant human-centric vendors will focus on external events as much as on integrations, and as much on forms and reports (and the underlying data to power those reports) as to events and integrations. They are three equal pillars of process: events, forms and integrations. You'll typically find the integration-centric platforms to be much more difficult around correlating these events into the business processes.
Conclusion
So here's the punch-line: Business process management will be unified across the enterprise, but it won't be because integration-centric and human-centric approaches converge. It will be because all business process platforms will look like what we call "human-centric BPM" today.
Today's "integration-centric" ERP and EAI platforms will continue to do what they do best: provide a useful conduit for normalizing data across the enterprise and providing a platform for service-enabling the infrastructure. And BPM platforms will be built to consume those services. Will this be a single vendor solution? The best of breed sure won't be, because the audiences are so different.
So it's fairly simple: do you believe you can automate everything a human does or every task they work on? Or do you believe that humans add unique value to given steps?
If it's the former - and this has been the traditional IT approach - then integration-centric is what you'll be more comfortable trying next.
If it's the latter, then you require a business-centric approach that gives:
- new visibility into the tasks, goals, SLAs and priorities of the 98% of the people in the business
- new tools to continually discover the patterns around the decisions the humans make,
- a new process improvement lifecycle to automate more work, continually, over time
The advance of IT doesn't stop with business-centric BPM, but it is the next great step on the journey of embedding technology into the very fabric of the business, so that constant tuning of the automation we use can be done by the business in exactly the same way we constantly tune products, pricing, suppliers and everything else in the business. The paradigm has to change, and the integration-centric approach is no advance at all. It's the same old thing, with a pretty graphical face. Improvement, no doubt, but a step-function advance? Not even close.
For real change, you need a new business-centric approach to technology, what we now call human-centric BPM.
Technorati Tags: BPEL, BPM, BPMS
You can't judge a book by it's cover. Today we have autobiographies that turn out to be fiction, and we have fictional accounts of the truth. Why, these days, you can't even tell a book by the book.
I guess it's always been this way. Neither Hemingway nor Malraux could have been who they were without their participation in the Spanish Civil War... who knows how much of their fictional accounts were true? Theodore White and Anonymous both participated in battles of a different kind and wrote non- and fictional accounts of each, respectively. I tend to think that Anonymous's fiction was more accurate than White's non-fiction.
And then there was Hunter S. Thompson. I mean, can you say in. the. moment.? He didn't write fiction or non-fiction. I don't know what he wrote. Drudge meets Jonathan Schwartz maybe. The First Blogger. Hunter S. Thompson: Patron Saint of Bloggers. I miss Hunter but you can't say he ever let a fact get in the way of a good sentence. He didn't even let a good sentence get in the way of a good sentence. And as for history or trends... he'd shoot before worrying about such weighty matters. He just participated and then wrote about what he'd participated in. Or wrote and then participated in what he'd written about.
What's all this got to do with "process"? Well, nothing really. But there is the ever-present hype factor of technology, the myth of the silver bullet all told with the straight face of the zealot-vendor or zealot-open-sourcer. What's real and what's fiction?
Today I read Kiran K. Garimella's new book The Power of Process. I was pointed to it by James McGovern, who says it's "one of the most enjoyable reads I have had in a long time." Hopefully James meant "one of the most enjoyable business reads" he's had in a long time. If not, James, here's a few truly enjoyable reads of my past month: Carter Beats The Devil, Peter Guralnick's Dream Boogie: The Triumph of Sam Cooke, and And A Bottle Of Rum: A History Of The New World In Ten Cocktails. Less enjoyable but a solid business read is Patricia Seybold's latest: Outside Innovation (get it?).
Not wishing to bury the lead (led, actually, if you're a journalist) below the sixth paragraph: I recommend Garimella's book for IT people who are tasked with "selling" BPM to the business. It's an effective distillation of many of the concepts of BPM and does a good job of staying above the fray. I think some biases do come out a bit... but overall Kiran does a very good job of dealing with the big topics of SOA, Six Sigma and LEAN and their relationship with BPM.
The book is written in the fictional story-style of The Goal, so it is easy to read and because it's written this way, he's able to have characters ask the questions you'll be asked and delivers the answers without it being dry.
Overall, Garimella walks through the TLA's with humor and gives pretty much just the right amount of airplay to them. He does a great job of articulating that BPM is not SOA, and also that BPM is more organizational than technical.
But the book suffers from some confusion. Although at the outset, Garimella has one of his characters state clearly that the implementation is distinct from the architecture [of SOA], he routinely gets implementation confused with architecture (and process management) throughout much of the book. This is particularly evident when he talks about modeling and executing. His main BPM protagonist in the book correctly identifies MDA (Model Driven Architecture) as the basis for abstracting the Process Model from the real-world implementation, but he then drives right down to the [so-called] benefits of the BPEL execution language. MDA is, in fact, rooted in the belief that the model is abstracted from the implementation. They, in essence, have nothing direct to do with one another. The model is transformed into an implementation, and the implementation can be one of many.
For those of you who don't know my biases, let me give it to you straight: BPEL has nothing to do with Business Process Management. It has nothing to do with BPMN portability. It is an implementation language that, if used at all, generally impedes agility and increases cost.
However, the principles of MDA are the basis for modeling the business. MDA rests on the foundation of having a CIM, or Computationally Independent Model. This is where agility, portability and re-factoring are enabled - at the CIM level. The corollary to being independent of implementation constraints means that I am also able to choose different implementation mechanisms for different types of problems. Who cares how a process is implemented if the following exists:
-- we share a common understanding of the process ("share the model")
-- that common understanding is faithfully executed ("the picture is the process")
-- the common understanding can be shared with others ("the model is portable")
The more the industry focuses on implementation, the more BPM is just the same old thing.
In addition, as Garimella points out really well, understanding messages in the context of the process (call this "BAM" for now) is far more important than requiring a particular implementation mechanism. Thus, modeling using an implementation-independent model is key to modeling processes that live (and report, and can be managed) on top of many different types of systems, services and people. Indeed, for processes at companies of any size whatsoever, being able to model "above" the execution layer is required, given the investment and magnitude of existing legacy systems.
And now for a word from our sponsor...
Of course, OMG (the Object Management Group, an international standards organization) is "father of MDA." And, the OMG's combination of BPDM (for BPM models) and UML (for SOA models) are both standards-based, computationally independent models that deliver the flexibility and portability required for business and service modeling. Transformations off of these CIM's into PIM's and PSM's (simply, the mechanism under MDA whereby a computationally independent model is transformed into a deployable application using one of a number of implementation languages) can be made to Java, BPEL, etc.
And this, James, also answers another question you had a while back, I believe: I think you asked in a blog about your ability to transform from a MOF-based metamodel into BPEL or other execution languages? Yes, coming soon... look for progress on this from OMG sometime between December and March when BPDM is approved (it's final version has recently been submitted, so a vote is forthcoming) and also some good work tying BPEL, BPMN, UML and BPDM together... and you'll be able to measure your effectiveness at doing this within an upcoming OMG-based Business Process Maturity Model...
Kiran Garimella's book is a good read for IT folks needing some concise explanations to technical topics... and watch the OMG for other good news on the standards front about many of the things Garimella writes about...
Technorati Tags: BPDM, BPEL, BPM, BPMN, James McGovern, OMG
The role of technology in the enterprise is changing. Of course, that's not a new idea, but I thought I'd take a moment and discuss how it's changing and why it's important.
The problems with big business today (and, increasingly, businesses in the SMB space too... let's say, above $500 million) is that they are getting too complex to manage effectively. Stated differently, the hodge-podge nature of the underlying systems in a company directly impact the reporting and visibilty that management has of the company. You know the systems and complexity I am writing about: all those which have either been home-grown, bolted onto or added to through acquisition of companies or expansion of product lines... "leading edge" ERP systems based on 1980's technology concepts and 1950's management concepts.... software contemplated before you began outsourcing and offshoring.
I know of one company that just went through an implementation of a "leading ERP application" and they now have less visibility into their products and processes than they had before. And this implementation was just completed! What the company failed to realize is that it wasn't transactions they needed a better system for... it was the newly fragmented processes introduced by their new contract manufacturing model. And ERP vendors offer little in the way of simplifying complex processes that live inside and outside the firewall.
The new software must offer a new paradigm, and new tools, that mask this complexity without forcing you to replace it. The new software must offer the ability to abstract your company and its capabilities so that the visibility and management is independent of implementation. The new software must offer you the ability to define how you want the company to be managed and how you want the company to behave, and then there must be direct, visible reporting linkage to the tasks you want performed and the behaviors you expect.
In short, you need to model your business, and you need to be able to manipulate your business via those models.
This isn't a very business-y word, "model", but it's where we're headed. This abstraction, these models, must allow you to easily see recurring patterns, so that the same model can be used to describe different parts of your business... re-using these models, or processes, over and over.
These models must have built-in notions of visibility and help you to understand whether your business is, in fact, running based on your model, or if you are off course. The model of your company needs to reflect compliance and trading relationships and a host of other details that you just don't have visibility into today... much less the understanding of how you might easily change those things or how that change would impact your performance.
There's a lot yet to be invented here but the first step is understanding this: in order to achieve the economy, the compliance and the agility you must have to compete in the 21st century, you need to eliminate the complexity that today's information systems impose upon you. And this means you need to be dealing with a software representation of your company that is an abstraction of the current "physical" state. This abstraction, this model-based world, is what Enterprise Process Management is about.
This is not about a graphical tool that let's you build an application faster. And this is definitely not about a simple "modeling" tool that doesn't lead directly to execution and visibility. Simply drawing a picture is not a "model-driven business."
A model-driven business requires a new kind of platform, a platform that runs in concert with your existing underlying systems, and helps to mask the complexities of those systems. In fact, so much of the complexity is masked that real people in the lines of business of your company will directly manipulate these models, developing reports, doing what-if analyses, determining in real-time exactly what part of which process has the most impact on some dashboard metric that just went "red."
This is about changing how you manage your company for the better, reducing the complexities (and therefore costs) that have been inserted by doing business in a more complex way than you did business even ten years ago. It is about taking back your business, and using simpler tools with more powerful insight so that, once again, the business runs the business.
Technorati Tags: 21st Century Process, BPM
Just wanted to send a quick note of congratulations to Bruce Silver... six months on the blogroll! During the past six months, Bruce has stimulated a lot of good BPM debate, has stirred up a flurry of commentary and deep analysis of BPM standards and has also brought a bit of needed humor into the mix. At one point he even had Oracle's Edwin K and I agreeing on something... will miracles never cease?
Thanks, Bruce!
Technorati Tags: Bruce Silver
Bruce Silver's post about process optimization garnered a comment by Fair-Isaac's James Taylor. Bruce has recently spent a lot of time with Lombardi's product (TeamWorks) and presumably with Savvion and BEA. I don't know if James has seen any of these products (I know he hasn't seen Lombardi's optimization technology). James suggests that human-based process optimization built into these products might be "light" predictive analysis and that they sound "cute." Sort of like the (probably apocryphal) old country song where the guy doesn't know whether to commit suicide or go bowling, I find myself of two minds. If we give some pretty deep insight into big problem areas for our customers, and it seems so simple, that's a good thing... but methinks James is suggesting this optimization stuff is simplistic, not simple. So I'll take exception...
It might be useful to understand what the business problem is, and then discuss the technology being delivered... if something solves a business problem, and it does it in a "light" way, I would think that would be preferable to solving the same problem in a "heavy" way, yes? We (Lombardi) take pride in the fact that normal, non-technical people can use our optimization tools and gain value... (the deep thinking is built in... making it "light" because we've done the "heavy" work that's required to make any hard problem seem simple). We think it's an example of where a platform can be more than just an engine, because it understands the context of what it's being used for, and leverages that understanding through innovative tools for the business.
The problem we saw is that in human activities, there hasn't been any scalable way to understand the behaviors inside that black box of an activity without doing all the hard work James refers to. Our customers confirm that previously, they've spent lots of money, some of it mis-spent, trying to gather the data, build the ontologies, etc. to help discover, define and implement rules to make human-based processes more efficient. And getting the data was the most time consuming bit in many cases.
With a good BPM platform, at least that part of the problem can be solved. We know the structure of the data that passes in and out of every human activity... that's a big step forward. Additionally, we understand the context of that data with respect to the process. Putting these two pieces together (strcutured data that is constant for every activity of every process authored in the BPMS) we can give new, deep insight into correlations that _seem_ to be occurring inside the process. Of curse, as James says, we don't necessarily have _all_ the conext, for example, legal regulations. Additionally, we don't know whether this is, indeed, a correlation or a coincidence. Human rigor is still required once a possible correlation is found, but now it's highly directed rigor. This doesn't make the analysis less valuable, less heavy or, even ugly. It means it solves the first part of the longer process of understanding and implementing new business rules. Indeed, we call this capability the discovery of non-obvious business rules.
The analysis can give information about correlations that are occurring (e.g.: on Fridays, when the order is from customer x and the amount is above y the outcome is <this> 98% of the time). You can apply various complexity levels, you can set various thresholds of numbers of instances required to be valid, etc.
It all seems easy because first, it's a structured system... the ontology exists, if you will and the users don't have to deal with any of that. To them, they just look at the process drawing. But inside the system, that is a rich, structured semantic that can be put to use. Second, we are limiting our understanding to what our system knows.... obviously, in the real world, people then use this new insight to focus what they then go look more deeply into. Today, without this insight, the further ("heavy"?) thinking is either mis-directed because you don't have statistical backup for what you're doing, mis-spent because you work on stuff you can instead of working on stuff you should, or in the majority of cases, simply isn't done because nobody knows where to even begin.
By the way, we don't believe the world is anywhere near ready for so-called autonomic business processes (in this human activity area) for the very reasons James talks about. There are too many unknowns (read: contexts) to make changes in real-time, on the fly. Using our optimization technology, though, you are able to kick off a process to work on the optimization(s) that are suggested once thresholds have been met.
Using the new data and the built-in context that the best BPMSs are generating to provide solutions and insight to business problems, or to make the understanding of those problems more focused is a Good Thing. You could even call it _very_ cute.
Technorati Tags: BPMS, Bruce Silver
 OK, I have the perfect opportunity to quote from one of Texas' great musicians, Terry Allen, but Dylan's new record is too good to cut short. So instead of linking to Terry's music, I'll just tell you that if you like your music straight instead of neat, you should pick up a Terry Allen CD... a good place to begin is with the CD containing two of his early '80's albums: Smokin' the Dummy and Bloodlines. It sounds like you're driving through Del Rio in 1959. But I digress...
Bruce Silver replied to my post on the book "SOA for Dummies" and there's a nice thread on his comments between the two of us... here's the link.
Technorati Tags: Bruce Silver, SOA
|
Lijit Search
|
Subscribe