Instrumenting Your Enterprise for Maximum Predictive Power

By James Kobielus

Business is all about placing bets and knowing if the odds are in your favor.

As I noted in my most recent Forrester report, business success depends on your company being able to visualize likely futures and take appropriate actions as soon as possible. You must be able to predict future scenarios well enough to prepare plans and deploy resources so that you can seize opportunities, neutralize threats, and mitigate risks.

Clearly, predictive analytics can play a pivotal role in the day-to-day operation of your business. It can help you focus strategy and continually tweak plans based on actual performance and likely future scenarios. And, as I noted in a recent Forrester blog post, the technology can sit at the core of your service-oriented architecture (SOA) strategy as you embed predictive logic deeply into data warehouses, business process management platforms, complex event processing streams, and operational applications.

The grand promise of predictive analytics—still largely unrealized in most companies—is that it will become ubiquitous, guiding all decisions, transactions, and applications. For the technology to rise to that challenge, organizations must move toward a comprehensive advanced analytics strategy that integrates data mining, content analytics, and in-database analytics. Already, we’ve sketched out a vision of “Service-Oriented Analytics,” under which you break down silos among data mining and content analytics initiatives and leverage these pooled resources across all business processes.

You may agree that this is the right vision but have doubt about whether there is a practical, incremental roadmap for taking your company in that direction.  In fact there is, and it starts with re-assessing the core of most companies’ predictive analytics capability: your data mining tools. As you plan your predictive analytics initiatives, you should avoid the traditional approach of focusing on tactical, bottom-up project-specific requirements. You should also try not to shoehorn your requirements into the limited feature set of whatever modeling tool you currently happen to use.

To become a fully predictive enterprise, you will need to take both a top-down and bottom-up approach to your data mining initiatives. From the top-down, it’s all about building and integrating alternate models of how your business environment is likely to evolve internally and externally. In our recent report on advanced analytics, Boris Evelson, Leslie Owens, and I sketched out the many business processes that can be enriched by predictive analytics.

So how do you instrument your company to become more predictive? For starters, assess whether your analytics tools support the following capabilities for developing, validating, and deploying predictive models:

• Model multiple business scenarios: You should be able to build complex models of multiple, linked business scenarios across different business, process, and subject-area domains, using such key features as strategy maps, ensemble modeling , and champion-challenger modeling.
• Incorporate multiple information types into models: You should be able to develop models against multiple information types, including unstructured content and real-time event streams, while leveraging state-of-the-art algorithm in sentiment analysis and social network analysis.
• Leverage multiple statistical algorithms and approaches in models: You should be able to develop models using the widest, most sophisticated range of statistical and mathematical algorithms and approaches, including regression, constraint-based optimization, neural networks, genetic algorithms, and support vector machines.
• Apply multiple metrics of model quality and fitness: You should be able to score and validate model quality using multiple metrics and approaches, including quality scores, lift charts, goodness-of-fit charts, comparative model evaluation, and auto best-model selection.
• Employ multiple variable discovery and assessment approaches: You should be able to build and validate models using various approaches for variable discovery, profiling, and selection, including decision trees, feature selection, clustering, association rules, affinity analysis, and outlier analysis.

How is this different from predictive analytics as usual? Traditionally, most predictive modeling specialists focus on the latter three capabilities: statistical algorithms and approaches, model quality and fitness, and variable discovery assessment. Most models are built in narrowly scoped business or subject domains—such as customer analytics for marketing campaign management—and only against structured data sources (such as relational tables). Traditionally, few predictive analytics projects have entailed modeling of multiple business scenarios across diverse domains--such as sales, marketing, customer service, manufacturing, and supply chain-- though in the real world these business processes are often quite interconnected. Also, many data mining initiatives fail to incorporate information from unstructured sources—such as text in call-center logs—though this content may be as important as what comes relational databases and other structured sources.

It’s very important to build multi-scenario predictive models against complex information sets, but becoming a fully predictive enterprise demands much more. To instrument your organization for maximum predictive power, you should also tool your advanced analytics to support the following capabilities:

·         DW-integrated data preparation: To speed up and standardize the most time-consuming predictive modeling project tasks, you should be able to leverage your existing data warehouse, extract transform load, data quality, and metadata tools to support a full range of data preparation features. These features include the ability to discover, acquire, capture, profile, sample, collect, collate, aggregate, deduplicate, transform, correct, augment, and load analytical data sets.

·         Deep application and middleware integration: To deliver models deeply into whatever heterogeneous SOA-enabled platform you happen to use, your predictive analytics tool should deploy on and/or integrate with a wide range of enterprise applications, middleware, operating platforms, and hardware substrate. You should be able to deploy models seamlessly into your data warehouse, business intelligence, online analytical processing, data integration, complex event processing, data quality, master data management, and business process management environments. And to play well in your SOA, your predictive modeling tools should support application programming interfaces, languages, tools, and approaches such as Web services, Java, C++, and Visual Studio, as well as emerging languages such as SQL-MapReduce and R.

·         Consistent cross-domain model governance: To avoid fostering an unmanageable glut of myriad models, your predictive analytics solution should support a wide range of tools, features, and interfaces to support life-cycle governance of models created in diverse tools. At the very least, your tools should enable model check in/check-out, change tracking, version control, and collaborative development and validation of models. To realize this promise, it should support a full range of tools, standards, and interfaces for import and embedding of models from other tools, as well as export and sharing of models to other environments.

·         Flexible model deployment: To execute modeling functions--such as data preparation, regression, and scoring—on the widest range of data warehouses and other platforms, your tools should support in-database or embedded analytics. And to scale to the max, your predictive analytics tools should deploy models to massively parallel data warehouses, software-as-a-service environments, and cloud computing fabrics.  Your advanced analytics tools should also support development of application logic in open frameworks—such as MapReduce and Hadoop—to enable convergence of data mining and content analytics in the cloud.

·         Rich interactive visualization: To deliver their precious payload—actionable intelligence—your advanced analytics tools should support interactive visualization of models, data, and results. Ideally, you should be able to visualize all of this in your preferred business intelligence tool, or in the predictive modeling vendor’s integrated visualization layer. Of course, you have every right to expect the full range of visualization techniques--histograms, box plots, heat maps, etc.—regardless of who provides the visualization layer.

As you can see, this goes well beyond data mining as usual. Forrester has a slightly different perspective on the development of the predictive analytics market than you’re likely to get from other sources. We see a robust, flexible, SOA-enabled data mining tools as the centerpiece of advanced analytics for fully predictive enterprises. The competitive stakes are too great for businesses to take the traditional silo-mired approach when implementing this mission-critical technology.

What do you think?

Service-Oriented Analytics: Tapping into the Predictive Smarts of Your Entire Organization

By James Kobielus

Advanced analytics is a key competitive weapon of companies everywhere. Visionary organizations are those that take a future-facing, analysis-driven perspective on new challenges. They do this by grounding management forecasts in solid historical information sets, leveraging and extending companies’ existing investments in data mining and predictive modeling.

To become truly future-focused, organizations must build out their predictive muscles through deepening commitment to these and other advanced analytics technologies, which also include interactive visualization, multivariate statistical analysis, text analytics, and massively parallel enterprise data warehousing. However, enterprises must be careful not to adhere to the common practice of implementing advanced analytics tools in tactical, application-specific silos. One of the downsides of this traditional practice is that diverse predictive modeling teams can find it difficult to share their deep domain expertise, best statistical approaches, and most powerful data exploration and visualization features.

How can companies realize the transformative potential of predictive analytics for business success? For starters, you must get rid of siloes that fragment your data mining initiatives into separate camps. You must also build a bridge between your data mining operations and the teams that manage your text analytics, business intelligence, complex event processing, and business process management efforts. And the key approach for silo-smashing is service-oriented architecture (SOA).

At first glance, SOA may seem like a foreign topic to many analytics professionals, but it shouldn’t be. In the broadest perspective, SOA refers to best practices for encouraging greater reuse, sharing, and cross-platform interoperability among key business resources. Typically, one associates SOA with reuse of one specific type of resource: application functionality that is distributed across heterogeneous, networked platforms. Nevertheless, key SOA principles—such as standards-based service virtualization, reuse, brokering, and governance—are as applicable to predictive models as to any other resource that lives online.

Predictive models empower your product managers, marketing specialists, risk managers, process analysts, senior executives, and other personnel with access to sophisticated forecasting, time-series analysis, and scenario-testing tools. Each model is a statistical encapsulation of your business’ current view of the future in some specific application, subject, or decision-support area. Incorporating the expertise of subject-matter experts, these models allow organizations to gauge the potential impact of future projects, campaigns, and other initiatives, and also to adjust execution of these initiatives in mid-stream.

Predictive analytics need not be a purely blue-sky planning tool. This technology can sit at the core of your SOA strategy, and leading-edge enterprises are in fact doing that. Companies in such verticals as financial and telecommunications are embedding predictive logic deeply into data warehouses, business process management (BPM) platforms, complex event processing (CEP) streams, and operational applications.

What will it take for your company to fully align your advanced analytics efforts with your SOA strategy? Most important, Service-Oriented Analytics requires an executive-level commitment to becoming a predictive enterprise on all levels. From the perspective of your existing predictive modeling teams, this will require an ongoing focus on collaboration across business, function, and subject domains. You should create a culture and offer incentives that encourage modeling professionals to reuse each other’s expertise on problems that cross multiple domains.

Reuse is everything. Here are some high-level guidelines for establishing a reuse-friendly Service-Oriented Analytics practice in your company:

• Reuse modeling best practices:Start by consulting Forrester’s report on setting up a Business Intelligence Solution Center (BISC), which we defined as “an institutional steward, protector, and forum for BI best practices.” Given that predictive analytics is a key segment of BI, you will find it necessary to incorporate this technology into your BISC’s scope.
• Reuse modelers: Cultivate a professional cadre of predictive modeling experts who are more than just wizards in advanced statistics and mathematics. Encourage subject-matter experts in all business areas to undertake predictive modeling projects and to team with modeling experts in other projects, applications, and business units. Provide incentives for modelers to regularly move between business units and subject domains, thereby spreading their expertise throughout the enterprise.
• Reuse models: You should begin to investigate predictive-model governance tools, which support version control, check-in/check-out, and other controls over models created in and imported from diverse tools. Model governance tools—from vendors such as SAS, SPSS, and KXEN--facilitate reuse, consolidation, combination, and cross-synthesis among disparate models. And you should also investigate options for embedding predictive models within BI, BPM, and other operational applications, thereby leveraging your growing analytic asset into new deployments.

As you deploy predictive models into operational applications, you should provide other applications with SOA-based access to them through Web services, Web 2.0, and other standardized interfaces. In that way, you will be creating a critical bridge to your application development teams and be creating a thoroughly Service-Oriented Analytics environment.

Your first steps down this road are clear. Forrester will be happy to assist you in developing a detailed enterprise roadmap for Service-Oriented Analytics. In so doing, you’ll be better able to tap into the future-facing analytic expertise that exists throughout your business.

Podcast: Transparency: The Next Step In Compliance

Our latest featured podcast is Craig Le Clair's "Transparency: The Next Step In Compliance".

In this podcast, BP&A Principal Analyst Craig Le Clair advises listeners to prepare for the next regulatory onslaught. One way to do this, he recommends, is by converging BPM and BI.

We look forward to your questions and comments.

---

Subscribe to Business Process & Applications podcasts through iTunes.

Subscribe through RSS.

Process Data Management: Like Your Brain And Your Heart, BPM and MDM Can’t Survive Independently

By Clay Richardson & Rob Karel

 It's an age old question:  Which came first:  the data or the process?  Okay, not an age old question, but an interesting one to ponder nonetheless!  Of course the answer depends on who you ask.  Ask most Business Process pros and the reply:  "Process existed even before computers. In fact I saw on The Discovery Channel where they found a process map in King Tut's tomb. No joke..."  Ask a Data Management pro and you're likely to hear: "Data was invented by the Pharaohs - you ever hear of a little thing called 'numbers'?"  

In upcoming research we tackle this vexing question and conclude that process and data are of course inseparable (shocking we know).  Unfortunately, most Business Process pros, Data Management pros, and vendors we interviewed couldn't see the forest for the trees.  In fact, in our recent MDM Survey, only 11% of respondents said that their MDM and BPM initiatives share the same cost center and team members that work together on a daily basis to develop solutions for the business.

In many ways, master data management (MDM) and business process management (BPM) represent two different sides of the same coin when it comes to business optimization and transformation.  So, why is there so little collaboration and interaction between Business Process and Data Management professionals?  There's plenty of blame to go around:

• Business Process pros don't find data sexy. While most process improvement initiatives pay lip service to data quality, only a small handful take data seriously and incorporate data modeling and data mapping into upfront discovery efforts. BPM teams typically focus on process first, user experience second, and data is an afterthought - no one ever asks if the data is clean until it’s too late!
  
• Data Management pros value clean data over process context.  "If we create clean data, then they will come" is often the mantra of Data Management pros. Unfortunately, the person coming is the CFO - asking "why are we spending so much money on something when we can’t articulate its business impact?"  In other words, Data Management pros often fail to provide cross-enterprise context for MDM.
  
• BPM Suite vendors conveniently MIA on the issue.  Some argue that SOA is the silver bullet to bridge the gap between MDM and BPM initiatives.  While SOA can definitely address reusability and architecture issues, many BPM teams come to realize the importance of master data too late into their initiatives.  While BPM suite vendors provide basic tools to define process variables, only a few (Lombardi/Siperian, Appian, and Polymita) accept some responsibility for keeping process data in sync with master data sources.
  
• MDM vendors focused on data governance and stewardship only.  The good news is these MDM vendors do in fact recognize that business process plays a major role in their success. The bad news is they are only actively addressing one side of the problem: the business processes and stewardship roles that govern the administrative workflows within the MDM tools themselves. The MDM vendors are not actively influencing the business processes that consume and depend upon the master data these vendors provide.

Although process and data professionals may not see it, like your brain and your heart, BPM and MDM are interconnected and one cannot survive for long without the other.  Our upcoming research, "Warning: Don't Assume Your Business Processes Use Master Data," highlights the fact that process improvement initiatives face a vicious cycle of deterioration and decline if master data issues are not addressed from the outset. And MDM initiatives face an uphill battle and certain extinction if they're not connected to cross-cutting business processes that feed and consume master data from different upstream and downstream activities.

Earlier this year, Forrester highlighted the emergence of "process data management" in our BPM Tech Radar report.  This new category in the business process landscape organically merges BPM and MDM disciplines and capabilities to provide the enterprise with one version of "process and data truth".  

Over the next several months, we will publish a body of research that scopes the process data management challenge, provides best practice for combining process improvement and data management initiatives, and presents case studies highlighting teams that have successfully integrated these two critical capabilities.

Why It Matters?

Call it what you like, the consolidation of process improvement and data improvement is inevitable.  Organizations looking to minimize operational risk and boost adoption on BPM initiatives must incorporate data modeling and data management activities for cross-functional process improvement projects.  Additionally, organizations looking to increase the visibility and importance of master data must identify and harness the most critical business processes that generate and consume mater data.  These are just starting points for bringing process and data closer together.  Most importantly, senior management must foster collaboration and provide cross-training between these two siloed disciplines to begin this long overdue paradigm shift...

What’s Your Take?

We want to hear from you.  Let us know whether you think there is a real need to synchronize MDM and BPM activities? Do you think BPM vendors should accept some responsibility for keeping process data synchronized with master data sources? Alternatively, do you think MDM vendors should be doing more to educate the marketplace? Also, let us know if you have a process data management success story, or lesson learned that you want to share.  Post your thoughts in the comment section or feel free to shoot us a quick e-mail at crichardson@forrester.com or rkarel@forrester.com.

When To Use A BPM Suite?

By Connie Moore

I was going through a bunch of old slide decks last week and came across this one particular slide that struck me.  I think it gave me pause because I don't normally use the slide, and I hadn't seen it in a long time.  I think the material is workwhile for anyone thinking about using a business process management (BPM) suite, so here goes.

Consider a BPM suite when you need to:

• Change processes frequently. This is probably the most important reason to look at using a BPMS, but a few years ago you wouldn't have seen this on the list, much less anywhere near the top. Back then, everyone preached the mantra that you should find a repeatable process and use BPM to automate it.  Maybe this came from a Six Sigma view of the world in which practitioners were trying to drive out variation in order to reduce defects and increase quality.  Anyway, the old thinking has been turned on its head now: use BPM for processes that constantly change (in addition to the highly repeatable ones) because processes that constantly change are 1) hard to automate and 2) probably some of your highest value processes because they are usually people and knowledge intensive.  A BPMS coupled with a continous improvement mindset (this latter point is the really important part) can really make a difference when it comes to processes that change.  And let's admit it right now--business processes change a WHOLE lot more than we think they do.
• Automate and monitor processes across the value chain. We are kidding ourselves if we think that processes start and stop within the walls of the organization.  To really understand a business process, you have to look at it from the customer perspective, and analyze all the steps involved in the business process, including steps that happen outside the oranization--say at the suppliers, the business partners, the dealers, the franchisees, and the customer.  It's challenging to automate processes across a value chain and a BPMS can help.  But the software is definitely not the hard part; getting everyone to agree on the process is the hard part.  That's where industry frameworks can make a big difference.
• Support cross-functional processes. We still get inquiries from clients who want to start their BPM intiatives within a single department. They think this way because they want to lower their risk and learn from the first departmental implementation.  But at its heart BPM is about tackling end to end business processes, and that means you should look across functional departments, including the white space between functional groups where work gets lost.  An example of a lower risk cross functional process would be employee on-boarding, which goes outside the HR department.  You can still address the risk factor without having to limit your BPMS implementation to a functional group.  Anyway, if you need to automate a cross-functional process, a BPMS is a good way to go about doing it.
• Allow business users or customers to monitor the status of requests or work in progress. Fed Ex and Amazon have forever changed expectations about monitoring the status of a request or order.  It's no longer good enough to expect customers to stay in the dark or be happy with e-mail updates.  Customers and others making requests want to peer into the process to figure out what is going on.  You can turn this into a huge customer benefit if you do it right.  And BPM suites are specifically designed to monitor the status of work--whether inside the organization or outside it.
• Extend the life of legacy apps. This is a great advantage of a BPMS.  If you have an older application, or a group of older applications that need refreshing but there's no budget to rewrite them/replace them, then a BPMS product can be implemented on top of the application(s) to become the layer that integrates apps or delivers additional value to the workers using the apps.  Many companies that have implemented BPM suites have found that it cuts substantially into their maintenance backlog and reduces maintenance costs as well.
• Collect work metrics or meet SLAs. As BPM suites matured, they began to offer strong process monitoring capabilities for business managers.  It's now possible to monitor work in real time, or look at analyses of work that has already been processed.  By setting key performance indicators, BPM suites can become powerful management tools for managers and executives--not just for monitoring work in process but also for redirecting work when and if conditions require.
• Improve inaccurate, inconsistent or laborious manual work. This one is a real beauty for companies that have fallen way behind on refreshing their IT systems.  I've personally seen companies realize as much as $5 million in savings the first year after implementing a BPMS because they had 1) fallen behind and relied upon laborious and duplicate data entry processes that generated data inaccuracies and customer satisfaction issues, 2) had massive, even heroic, manual activities associated with getting work completed and 3) relied extensively on paper documents and forms that were constantly misplaced. By implementing a BPMS to automate an archaic process quagmire, the savings can be huge.
• Capture process knowledge. Many companies in regulated industries (like manufacturing, pharmaceuticals, utilities, etc.) and government agencies are facing a steep climb in replacing retiring baby boomers.  A US government study just came out last week that says more than 270,000 workers will be needed for "mission critical" jobs over the next three years.  When organizations face that level of employee turnover, they often start documenting their business processes and nailing down all types of tacit and implicit knowledge.  Definitely, modeling your business processes helps the organization gain more process knowledge, but there is a big caveat that comes with this approach.  Many organizations fall prey to the ideat hat they can document their business processes in their favorite tool (Powerpoint, Visio, a process modeling too) and it will provide great value over time.  In reality, unless the process model is tied to an execution engine, it will be outdated very quickly.  That's because processes change much more frequently than we realize (see bullet 1 where I started . . . ). A BPMS product is one way to model the process for process knowledge and also link it to an execution engine that makes it much easier to update the process version as it changes over time.

I hope this list is valuable to you.  It caught my eye and I thought I would share it.

Is BAM Relevant In The Age Of Lean Processes?

By James Kobielus

In any dynamic business environment, the last thing you want is to indulge in navel-gazing. If you’re finely attuned to monitoring internal processes, but are not adept at responding to breaking events or anticipating the future, you will find yourself marginalized in the new global economy.

In a turbulent world, the most successful companies are those that stay lean--in other words, trimmed of excess overhead, fit for new challenges, and flexible enough to evolve rapidly. Forrester advises customers to make their business processes leaner, through such measures as reducing the number of steps, routing paths, participants, decision points, milestones, and revisions. As you do, you will find concomitant improvements in speed, cost, quality, and customer satisfaction.

Clearly, you can’t do that well if you don’t have, at the very least, the means to monitor a wide range of business processes in unified dashboards, reports, and other applications. That’s where traditional business activity monitoring (BAM) tools, which are a key component of most business process management (BPM) environments, play a critical role. However, critical as BAM may be, it is often deployed in a predominantly navel-gazing process-tracking capacity (remember what that “M” stands for) and, as such, is as much part of the problem as the solution.

Why? Well, for starters, most BAM environments are deployed in conjunction with specific vendors’ BPM platforms--hence can only track the subset of business processes that run on those platforms. But, even more limiting, BAM dashboards are often the stand-alone province of process administrators. Only in a handful of  BAM-using organizations do alerts and metrics escalate beyond the process administrator level and trigger the necessary human and automated workflows necessary to respond to breaking issues--or nip them in the bud before they can become issues.

To stay relevant, BAM needs to evolve in the age of lean processes so that it can become a tool for business agility at all levels. Next week, Forrester BPM analyst Clay Richardson and I will do a podcast on this very topic. In  that podcast, and in a joint presentation that Natalie Petouhoff and I will do at Forrester Business and Technology Forum in Chicago in October, I’ll sketch out a vision for the next-generation of BAM (which I half-jokingly call “uber-BAM”).

Here is a rough sketch of the maturity levels of BAM's evolution to realize this vision:

• BAM Level 1: Business activity monitoring: This is today’s BAM baseline. Essentially, it combines BPM with business intelligence (BI), interactive dashboarding, and complex event processing to deliver process metrics to consoles used solely by human process administrators.
• BAM Level 2: Business action mobilization: This is the BAM level that many forward-looking users and vendors have implemented. It combines all Level 1 functionality with business rules engines (BRE) to drive sophisticated human and automated workflows in response to breaking events. It puts the “immediate action loop” into the BAM equation.
• BAM Level 3: Business adaptability management: This is the promise of truly lean uber-BAM, and is found only in a vanguard of visionary  business environments. It combines all Level 2 functionality with embedded predictive-analytics models, which are developed and maintained by business process architects and/or subject-matter process experts. Continuously mining historical and real-time metrics, these in-process analytics drive automated “recommendation engines” that adapt coordinate response to changing conditions. Recommendation engines enable human and automated decision agents to seize opportunities and neutralize threats well ahead of the curve.

Going forward, this new vision of BAM’s evolution and promise will inform Forrester’s coverage of process agility and optimization.

50 Things I Know About Business Process Management

By Connie Moore

I just got on Twitter yesterday. My Twitter handle is “cmooreforrester”.  Wow, what an experience.  I had 54 followers in 24 hours, and now have 83 followers in 2 days.  In honor of the occasion, I thought I would write the 50 things I know about BPM, in 140 characters or less for each entry.  (OK, don’t hold me to the 140 character count; I didn’t count the actual sentence length.)  Hope you enjoy it and get value from it. The 50 things I know about BPM:

1. Business process management is a discipline, not a technology.
   
2. The discipline is grounded in Lean thinking, continuous improvement, total quality management, and six sigma.
   
3. Business processes constantly change, even though many are unaware of it.  For example, the products change, the marketing approach changes, suppliers change, the business strategy changes, the organizational structure changes, and if that isn’t enough, the competition and regulatory bodies force change.  Or the company gets bought or acquires another company.
   
4. BPM projects should focus on how to manage and capitalize upon constant, unrelenting change.
   
5. BPM projects should also help the business person by providing all the information he/she needs within the context of a process, and all the collaboration tools needed within the context of the process.
   
6. BPM projects should be led by business, not IT, to avoid failure.
   
7. Business-led BPM projects can still fail, so best practices matter.
8. Process governance is an important part of BPM initiatives.
9. Process governance and data governance initiatives should be aligned.
   
10. The best place to start with a BPM initiative is in cross-functional processes with high volumes of manual work that create a lot of pain in the organization.
    
11. Change management is critically important; the biggest area of resistance is usually in mid-level managers who are in charge of functional groups.  They tend to dislike cross-functional processes because they perceive a loss of power.
    
12. By choosing a process that has lots of pain, it overcomes the internal resistance.
    
13. A BPM center of excellence (COE) is essential for success.
    
14. Many companies establish a business process or business performance or business improvement  group that sits in the business and supports all the business domains in their BPM efforts.  This group usually owns the BPM COE.
    
15. The companies that are mature in their process initiatives usually have business process organizations (I call them business operations) sitting in the business.
    
16. Aspiring companies working hard to bring about BPM change often have business process experts/execs sitting in IT with a dotted line to the business.
    
17. One of the biggest challenges in BPM is finding skilled resources to interview business users, design processes, analyze processes, and optimize processes.
    
18. Many companies look to business analysts for their process analyst needs; however, the success rate is only about 50% (based on discussions with BPM COE managers).
    
19. Building process skills is a big challenge; one way to do it is combine an IT person and a business person into the process analyst job — sort of a 2-in-the-box approach.  It helps with cross-training.
    
20. Some of the organizations to go to for help with BPM are:  ABPMP, BPM Focus, WfMC, AIIM.
    
21. Some vendors have jumped into the skills building business or efforts because it is a critical path to their success.
    
22. Vendors that help with skills building include:  IBM (see the Blueworks Web site), and SAP.  Also, Lombardi Software now offers a University for courses in BPM.
    
23. BPM suites are tools that help with business process management initiatives.
    
24. BPM suites (BPMS) usually have these components: design, execution, analysis, and optimization, with a feedback loop to the design component for process improvement.
    
25. Process versions should take less than six months to develop and deploy.
    
26. Usually a process goes through 3 versions to make it really right; sometimes up to 7.  But by then, something has probably changed in the business, making it important to keep updating the process.  Get used to change. That is what BPM is all about.
27. Some organizations have broken processes and just want a BPMS to automate a process.  The results can be spectacular, but these approaches don’t really capitalize on the full value of BPM.
    
28. Companies that focus on automation typically do not use simulation and feedback loops into the process design.  To move up a level in business benefits, consider using simulation as part of the process optimization effort.
    
29. Even worse, some companies only want to model processes and not put them into an execution environment.  The models get out of date quickly and the value of doing this is very limited.
    
30. In contrast, some organizations want to move beyond automation and continuous improvement for a single process.  They want to have process consistency across all instances of the process.  For example, a company may have 50 different call centers around the world.  Taking into account local cultural differences and laws, they strive to make the process the same in all locations.
    
31. Too many organizations just focus on the structured part of the process. You have to look at the entire process or the entire work environment, not just part of it.  It’s critical to look at people (design for people, collaboration, social media, etc.), process (the ad hoc and structured process) and information (data and content and all the next social media artifacts).
    
32. Case management is the term that describes bringing people, process, information together to work on a case folder.
    
33. A BPMS does not require SOA to run, but SOA and BPM are closely linked, and BPMS deployments should use Business Services whenever possible.
    
34. SOA needs BPM to make Business Services actionable and relevant within processes.
    
35. IT used to resist BPMS.  Now IT increasingly sees BPMS as a way to support rapid development, lower maintenance costs and cut into the maintenance backlog. If you have resistance from IT, use these arguments to persuade them.
    
36. BPMS products do not require an enterprise service bus component within the product; it is possible to use existing middleware with pure-play BPMS products.
    
37. Agile development methodologies are critically important for BPM projects.
    
38. Process wikis are a new and exciting way to design processes.  They are lighter and easier to use, and often SaaS based.
    
39. Process modeling and data modeling initiatives should be aligned.
    
40. Master data management or data quality and BPMS deployments should be aligned because cross functional processes access data from different sources, and data quality issues often surface in the execution.
    
41. Workflow is not the same thing as a BPMS.  Workflow is the forerunner to BPMS and mainly focuses on design and execution.
    
42. Some of the document management products only offer workflow, not BPMS.
    
43. The BPMS market is fragmented, with probably more than 100 vendors (that’s a guess on my part, not a fact.)
    
44. The BPMS vendors have different biases about how work is done that gets reflected in their products.  It is vitally important to understand their history and philosophy of work, because it might not match yours.
45. The BPMS vendors fall into 3 camps:  those that focus on processing documents or other unstructured content; those that concentrate on SOA, middleware and integration; and those that provide a rich work environment for people working primarily on structured processes.
46. The BPMS market is slowly consolidating through acquisitions; eventually the human-centric and integration centric markets will merge. 
    
47. The document-centric market will take longer to converge into the other BPMS segments.
    
48. Business rules engines (BREs) are an extremely important technology for BPMS. In fact, BREs are more important inside BPMS than standalone.
    
49. Many vendors offer process templates.  Sometimes these are a gimmick and sometimes the process template or framework is valuable.
50. Things to look for in a process template include:  process models, best practices, sample code, and a bundle of processes that support an industry sector, not just a single process.  

SAP and TIBCO? Too Juicy Of A BI Rumor Not To Comment On

By Boris Evelson

I typically don’t like to comment on rumors, but this one is too juicy (from the BI point of view) to pass by. Even though TIBCO’s business is primarily in application and process integration, enterprise service bus, middleware, messaging, etc., Business Intelligence implications of the rumored SAP/TIBCO merger are huge! By acquiring TIBCO SAP will get:

• A leading position in the in-memory analytics. In-memory analytics, provided by TIBCO’s acquisition of Spotfire a couple of years ago, is a very different animal then traditional BI. First it enables ultimate flexibility and nearly instantaneous response. Also, while power analysts using their own copies of MOLAP cubes free to modify data models as they see fit, a data modeling step is still required before reporting and analysis can be performed. In-memory data models do not require that step, since all of the calculations and aggregations can be done at RAM speeds and therefore require little, if any, design and preparatory work. For example, there are times when analysts need to treat a continuously variable numerical value (like sales price) not as fact, but as a dimension. While conventional OLAP tools make this very difficult, in-memory models do not require a distinction between facts and dimensions — any element can be instantaneously used in either capacity.



• A leading position in business optimization. TIBCO/Spotfire provided a combination of at least 3 separate technologies that are necessary for the drive toward business optimization. BPM (Business Process Management) vendors address efficiency gains, BI vendors provide visibility into business results, and BRE (Business Rules Engines) optimize decision-making. Together, the three technologies foster business optimization, where an optimized enterprise is efficient, effective, and agile. Organizations need BI tools to understand the results of BPM processes; analytics to determine the context of processes and the conditions for rules; rules to determine which actions people or processes should take; and BPM to manage the flow of work and information.



• Contextual analytics.  BI/analytics must be context-aware to be useful. In the converged world of process, rules, and analytics, business people cannot be expected to start with a blank slate and select from a variety of KPIs, KPMs, facts, and dimensions as is required today. Since it is the process that brings up the dashboard automatically at the right place and the right time, the process is aware of the context and what decision needs to be made. The process can therefore prepopulate that dashboard with the right KPIs and KPMs, or the right intersection of facts and dimensions that the user needs to analyze the situation and make the appropriate decisions.



• Address a potential advanced analytics gap left by IBM/SPSS deal. Traditional BI tools do not foster predictive and prescriptive insight.  If architected and designed properly, traditional BI applications provide deep insights into past and present events, as well as help identify patterns in past sales, marketing, supply chain, and financial performance. But in this new age of future-facing business analytics, any BI user without strong advanced analytics capabilities is seriously deficient and at a competitive disadvantage. Traditional BI tools effectively answer past-facing questions such as “what happened?” and “why did it happen?” but do not offer much assistance with proactive concerns such as “what will happen?,” “what may happen next?,” and “what could possibly happen if I take action X vs. action Y?” For that kind of functionality, SAP Business Objects currently relies on the OEMd version of SPSS – a company that is now going through pre-merger integration process with IBM. Even though both IBM and SAP state that all SPSS current commitments and OEM relationships are alive and well, we know better. We know that SAP has to protect itself from IBM and needs to make a similar acquisition in the near future. Insightful, recently acquired by TIBCO will easily fill in that gap.

Still think it’s just a rumor?

Software AG Announces IDS Scheer Acquisition: Is The Tail Wagging The Dog?

By Clay Richardson, Ken Vollmer, and Connie Moore

Only two years after acquiring webMethods, Software AG shakes up the BPM world once again with its announcement to acquire leading process modeling vendor IDS Scheer.  Since the webMethods acquisition, Software AG has continued to push the envelope on combining solid human-centric and integration-centric capabilities under a single vendor roof.  With the IDS Scheer acquisition, Software AG is sending an indisputable and clear message to the market:  "We are a major BPM player, hear us roar!"  Or should it be, "hear us bark?"

In many ways IDS Scheer has more brand cachet in business process improvement circles than Software AG, leading us to wonder: Is the tail wagging the dog on this deal?  Is Software AG buying IDS Scheer, or is IDS Scheer really buying Software AG?  The truth is that Software AG is buying a global brand that has the potential to completely remake Software AG into a process improvement powerhouse.

On the surface, Software AG has positioned this acquisition as a vehicle for opening up new global markets they are trying to further penetrate - such as Latin America and Asia Pacific.  Specifically, they expect to expand their consulting footprints in these markets in order to support increased license sales.  No doubt, Latin America is poised for growth and Software AG has timed this acquisition to capitalize on projected growth in Brazil and Venezuela, which continue to see single and double digit increases in technology spend.

Looking beyond surface observations, we see three key reasons why this acquisition makes sense and why it will play well in the market place:

• The Need For Execution - IDS Scheer needed an execution engine in order to remain relevant and credible in the eyes of process pros responsible for expanding enterprise BPM initiatives.  Although the majority of IDS Scheer's customers use Aris for SAP implementations, many of these customers are looking for simpler alternatives to SAP for process execution.  Looking forward, Aris customers could build out their process models and decide whether to deploy to SAP or webMethods (or another BPM environment) - depending on the process' complexity and reliance on SAP data and applications.

• The Need For Business Empowerment - Since the webMethods acquisition, Software AG has struggled to break away from its "integration-centric" roots.  Ask the average CIO about webMethods and she's likely to say, "Yeah, they really do a great job with EAI."  However, the reality is that over the last three years webMethods has completely revamped the platform to truly support human-centric processes while maintaining key integration-centric components.  With the IDS Scheer acquisition, Software AG doubles down on its commitment to empower the business to align process initiatives with key strategic goals and objectives.  

• A Seat In The C-Suite - Ultimately, this acquisition will increase Software AG's stature and profile within large enterprises - moving webMethods from a technology component in the IT stack to a key ingredient in their customer's process strategy.  Keep in mind that IDS Scheer is well regarded as a platform for supporting large BPM Center of Excellence efforts, which typically enjoy healthy support from CEO's and COO's.  

So, what's it mean?

• Aris customers shouldn't sweat - Aris customers should breathe easy, since Software AG has agreed to treat Aris as a separate entity, with its own roadmap and strategic direction.  This was a smart move by Software AG, in order to not rock the boat with key Aris partners SAP and Oracle.  

• Watch for SAP's response - Middleware consolidation is accelerating.  The acquisition of IDS leaves SAP with no viable options to shore up the NetWeaver stack other than to look at Informatica or Software AG, though it’s been rumored for some time that SOA software was on their target list.  Rumors have also been rampant about a potential SAP acquisition of Software AG.  In addition to regaining control of the IDS Scheer modeling capability, there are additional factors that could make such a move beneficial for SAP.  For example, replacing NetWeaver XI/PI with webMethods would solve a persistent problem of interfacing SAP applications with the outside world.  It would also provide native EDI capability that SAP customers must currently obtain via SAP partnerships with CrossGate and Seeburger.  

• M&A activity will continue in the BPM space - In the current economic environment, many smaller BPM vendors are running out of runway to launch their companies to the next level.  These vendors are beginning to face the reality of acquisition or failure, and larger stack vendors (with cash) realize that now is the time to go bargain hunting for struggling vendors.  We expect M&A activity to continue in the BPM space; however, it will not be in the most obvious pairings - as signaled by the Software AG and IDS Scheer situation.

Our Point Of View

Overall, Forrester expects this to be a successful deal for both Software AG and IDS Scheer customers, with minimal disruption and adverse impact on combined customer portfolios.  Software AG customers will benefit from an extensive process analysis modeling platform and professional services organization that can support multi-million dollar, multi-year BPM initiatives; and IDS Scheer customers will benefit from a robust execution engine that can support human-centric and integration-centric business processes.

The big loser is SAP - and to a lesser extent Oracle.  Both use IDS Scheer to augment their internal process modeling capability.  Now they will have to rely on a competitor for this functionality.

In the end, it really doesn't matter if the tail is wagging the dog - all that matters is whether the dog's bite matches its bark.  And in this case, the combined Software AG / IDS Scheer offering seems to be a good match.

Sound Off

We want to hear from you.  Let us know what you think of the IDS Scheer acquisition.  Do you think this acquisition will have a net positive impact on the BPM market?  Do you think the combined technology portfolios of Software AG and IDS Scheer are complimentary and will improve their customers’ process improvement efforts?  How do you think SAP will respond?  Post your thoughts in the comment section or feel free to shoot us a quick e-mail at crichardson@forrester.com or kvollmer@forrester.com.

It's Getting Crowded In This Cloud

By Clay Richardson

Based on the recent wave of announcements flooding my inbox, BPM vendors are now stampeding to the cloud party.  Over the last two months, I have received no less than 6 cloud-related announcements from various BPM vendors.  So here's the running time line:

• Singularity
• Cordys Process Factory (partnership with Google Apps)
  
• IBM BPM Blueworks
• Vitria M3O
• Appian Anywhere (announcement of free version)
• Software AG AlignSpace

This is starting to feel like the 1849 Gold Rush, or at least what I imagine it was like, based on what I learned in school (since I wasn't there smarty pants).  So where's the gold – since we don't see evidence of any vendors making wild sums of money off of BPM SaaS at the moment?

In the near term, smart BPM vendors see the cloud as a cost-effective marketing approach for "try-before-you-buy."   Customers can play around with the technology, build a few processes, prove initial business value, and then plunk their money down if they're convinced.  Think of it as an optimized sales tool - no troublesome technology installs that could derail the vendor's sale cycle.

For firms like Appian and Lombardi that began prospecting (sticking with the gold rush analogy) early, they are beginning to see a few shimmers of gold, in terms of attracting new customers to their brand and differentiating themselves as early pioneers in the BPM SaaS space.  But the real mother lode is still far off.  And with the stack vendors beginning to crank up the "public vs. private" cloud debate, it will become more difficult for smaller players to control the BPM SaaS conversation in the future.  For example, Oracle and IBM are now touting the importance of the "private cloud" (the new term du jour for grid computing, data centers, etc.).

Why It Matters

With software vendors stampeding into the BPM Cloud, customers will come to expect well-defined software-as-a-service strategies when evaluating BPM technology.  At a minimum, vendors need to show customers that BPM SaaS is on their roadmap or run the risk of being tagged as laggards.  In the near term, these same customers will likely end up buying on-premise BPM Suites, but will feel more comfortable with vendors that are not blind to the cloud computing trend.

For customers, it means you now have more choices when it comes to test-driving BPM Suites before plunking down your money.

And for the industry, it means lower barriers and the potential for accelerated BPM adoption.

Sound Off

I want to hear from you.  Let me know what you think about BPM Software-as-a-Service.  Do you think this latest stampede is a game of vendors playing catch up?  Do you think BPM SaaS has the potential of expanding and growing the BPM market?  Post your thoughts in the comment section or feel free to shoot me a quick e-mail at crichardson@forrester.com.