BI and BPM is more than slicing and dicing your workers

What does Business Intelligence (BI) get a business? Incredible insight into the performance of the business, its operations and the impact these things have on the bottom line. Which is great, until it shows that certain parts of your business are really messed up or just extremely unpredictable (which when you are trying to achieve consistent results can be a problem).

So what do you do now? Find a way to improve the performance and repeatability of business operations and find a way to get visibility into the opaque areas that are causing you so much unpredicatability. Both of these are targets for Business Process Management (BPM) tools, since improving and automating processes can provide huge benefits in the way operations run. Great story. The end... But not quite.

Its okay. I don't have a marketing team watching over my every word, so I don't have to claim that BPM solves everything, since it doesn't. Vendors and consultants forget that BPM needs to truly be part of the BI landscape. And not the vague attempts some BPM vendors have made by trying to force fit analytics tools onto process engines to provide in depth slice and dice information on the performance of individual workers. In my opinion, this is missing the point.

What do I mean? I'll answer a question with a question. What value is there in pumping basic activity timing information from your BPM engine into a multi-dimensional cube so you can analyze the crap out of an individual step in a process, when you can do much of the same with standard BPM database tables, and an Excel pivot table? Unless the process represents millions of items a day, the level of scrutiny that analytics can provide at such a granular level is potentially misplaced. BI is not just having a cube and putting some pretty visualization in front of it.

Here is what the true intersection of BI and BPM is in my opinion. It is the ability for BI to help you identify where in the business you can see problems, then using BPM to rapidly:

• Design, implement and run improved processes to help fix the problem
• Provide visibility into the work inside the process at a point in time with real business metrics such as the value, risk and profitability of that work
• Enable individual work items to be profiled and prioritized (against these business metrics) to drive the process towards greater profitability or revenue
• Track information that can rapidly feed back up to your core BI, to show how performance and business metrics are trending

Using all this great BPM value, make sure that BI shows meaningful information from it. Down in the business operations, a KPI is maybe that the average time to process a specific three steps in the process has trended above 15 minutes 53 seconds. The manager there can work with that to fine tune the process. But I don't suppose the guy with a corner office 12 floors above really gives a crap. His question is whether the same operations are going to hit a profitability of 18.5%, a growth in revenue of 6% and reduction in costs of 2.5%. And what the hell can be done about it if it appears that's not the case, because that's one thing that will impact his bonus.

BI and BPM are complementary at many levels and should feed each other in many directions, and it takes more than a software vendor to make this a reality. Implementing both technologies to best effect in their disparate business environments, while ensuring that the sum is greater than its parts is a challenge. So maybe it is time for a few more consultants that understand both BI and BPM to help companies really see the potential.

A post from the Improving It blog

Download the podcast of this blog post

P2P payments without the PayPal

I had never thought of alternatives to PayPal that maybe my parents would trust. When it comes to sending money around, people are rightly cautious when it comes to the use of third-party services. And unfortunately PayPal has become a target for a large amount of phishing scams, unfortunately hurting their image through no fault of their own. It seems though that other people have been thinking of alternatives.

Yesterday I received a message from CashEdge, (who I mentioned in this blog in 2006 and it appears their PR team still has my name on file. The power of PR; it got you another mention!). They are talking about an new approach to person-to-person money transfers that could be offered by banks - i.e. the bank you already know and trust with your hard earned cash. It certainly sounds appealing. So what's the deal? According to CashEdge:

Today, CashEdge launched the first person-to-person payments service for banks – POPmoney – that will enable consumers to send email and mobile P2P payments directly from their bank account to friends, families, and others, using only an email address or a cell phone number. There has been a lot of buzz about P2P/mobile payments recently, but CashEdge offers three critical advantages: 1) POPmoney is the only service built specifically for banks; 2) CashEdge has a proven record of success in providing risk-management money movement services to the top national banks; and 3) unlike other payment networks, banks have a built-in customer base (current bank customers) for this service.

http://www.popmoney.com/media.html

So this sounds like a good idea for US banks, which are still tied to paper checks (cheques) and are desperately trying to find faster ways to move consumers away from them. It sounds like a potentially great source of new revenue which is effectively lost today to PayPal. And from what little I know of CashEdge, they have the ability to provide this solution to mid-tier banks that don't want to build it themselves, as a software as a service (SaaS) offering.

For me what will make or break it is not CashEdge, or the announcement of an offering that does not expect to have customers it can name until the summer (in which hemisphere?), but the pricing that banks attach to the service. Will they try and undercut PayPal, or will they charge a premium, knowing that mom-and-pop wouldn't use PayPal anyway. Go too high and mom-and-pop, with plenty of time on their hands will probably write that check, stuff it in an envelope and put a stamp on it.

Good luck CashEdge, but I'll believe it (POP) when I see it unfortunately and will happily continue using PayPal for now. That feeling is only reinforced by an announcement that seems way too early, or at least a missed marcom opportunity in the buzz and advertising strength of a bank saying, "Use our great (POP) service" and other banks saying, "How do we do that?". The credibility of P2P payments (at least in the US) rests with the banks, and their adoption of CashEdge, or other vendors that have been pre-warned that they have until the summer to make an announcement first.

A post from the Improving It blog

Download the podcast of this blog post

Tools are 'temporary body parts' (so pay attention to application design)

The BBC News website had an interesting story today: Tools are 'temporary body parts' The researchers writing in Current Biology showed some interesting, if not completely surprising results that after using a tool for an extended period of time, your ability to perform similar tasks without the tool become slower and more 'clumsy'.

"There is a great debate in neuroscience about the representation of the body and representation of space," said Lucilla Cardinali of the National Institute of Health and Medical Research (Inserm) in France.

The researchers were working with a metal grabber and seeing how its extended use affected the user's ability to grab things without the tool. Imagine the damage we do to our ability to perceive our own bodies and perceive the space around us after hours tied to a computer keyboard and a screen 2 feet from our faces. Go further and try and see the confusion of a human brain after extended use of Twitter, IM, phone, Facebook, etc. How confused is a brain in truly perceiving the relationship between location, timezones and human behavior; especially as every one of these mediums cuts us off from the real interaction that we have evolved to trust and enjoy in human relationships.

Now go one step further. Give a person in an office a new software application to use to do their day to day work. More than just email, but for example a new tool for creating quotes for an insurance underwriter. If as a person you are absorbed in that application to do your job, you adapt to the application's shortcomings and come to appreciate its strengths (or perhaps unknowingly adapt to things you just happened to find useful).

I watched the joy on some user's faces just a few days ago when we showed them a demo of a new software solution. They have been doing copy and paste of information between systems for a long time. One tiny piece of our new solution has a built in search with their main system, and the ability to click a result to use that directly in a new piece of work. A simple click and the smiles were shining.

The function took 5 lines of Javascript and some configuration. And it will probably be the most loved piece of the overall application. The users will hopefully come to adapt to (and therefore not be able to live without) other pieces of the solution, though its important to see how such small details can make tools so much more an extension of a person and lead to improved acceptance and productivity.

A post from the Improving It blog

Download the podcast of this blog post

Will the EPA block regulation on Carbon reduction?

According to the WE campaign (we can solve the climate crisis), the Environmental Protection Agency (EPA) has the opportunity to facilitate, or to stand in the way of, future regulation of Carbon emissions. This could strongly affect Obama's capability to influence climate change through regulation:

The EPA recently released a finding that would allow the Obama administration to limit carbon pollution. But it’s not final until the public weighs in and the deadline to submit comments is this Tuesday.
http://www.wecansolveit.org/page/s/epacomments

Based on this very sparse information, I wanted to find out a little more. Here is the result of scouring the web to find what is actually going on. The most understandable information I could find was based on a public hearing led by Dina Kruger, the director of the Climate Change Division at the EPA:

[on the EPA] proposal that finds that greenhouse gas emissions endanger human health and welfare, and that greenhouse gas emissions from new motor vehicles cause and contribute to the climate change problem under the Clean Air Act.

The EPA is unable to make any rules until all stakeholders have a change to comment. Stakeholders include car makers, big-oil, lobbyists and one or two hundred million individual citizens. The rest of the several billion people in the world affected by the decisions of the EPA are not represented.

How can people put their opinions forward? Visit the EPA comments page on the WE website is one option. The EPA website also hides away how to comment directly. Go to the bottom of the page: Regulating Greenhouse Gas Emissions...

For those of you wanting a little more background, I found this brief history (dating from 1999, with all the action in the last 2 years) of Carbon legislation at the start of the Public Hearing document.

In 1999, EPA received a petition to regulate emissions of four greenhouse gases from new motor vehicles and engines, under Section 202(a) of the Clean Air Act. EPA denied this petition in 2003.

A lawsuit was filed, which resulted in the Supreme Court decision in Massachusetts v. EPA, in April 2007, where the court rejected EPA's reasons denying the petition, and found that greenhouse gases are air pollutants under the Clean Air Act.

The court stated that the EPA administrator must follow the statutory criteria of Section 202(a) and make a determination regarding the role of greenhouse gas emissions for motor vehicles in contributing to the climate change problem.

The options for this determination were either that greenhouse gas emissions from new motor vehicles do cause or contribute to air pollution that may reasonably be anticipated to endanger public health or welfare, that such emissions do not cause or contribute to a threat, or that the science is too uncertain to make a judgment.

In July 2008, in response to the Supreme Court's decision, EPA published an Advance Notice of Proposed Rule Making on Regulating Greenhouse Gases under the Clean Air Act. This ANPR made no determination regarding endangerment but rather requested comment on the implications of making an endangerment finding, and the underlying science.

On April 17th, 2009, after a thorough scientific review, Administrator Lisa Jackson signed the proposed finding that greenhouse gases contribute to air pollution that endangers the public health and welfare of current and future generations.

The proposed finding identifies six greenhouse gases that are reasonably anticipated to threaten public health and welfare. The proposal also finds that the combined emissions of carbon dioxide, methane, nitrous oxide, and hydrofluorocarbons from new motor vehicles and motor vehicle engines contribute to the atmospheric concentrations of these key greenhouse gases, and hence to the threat of climate change.

EPA's proposed finding does not include any proposed regulation. And before taking any additional steps to regulate greenhouse gases under the Clean Air Act, EPA would conduct appropriate rulemaking process and consider stakeholder input.

Massachusetts - a low lying state is threatened by Global Warming, with the chance that it will lose a large quantity of land and housing (currently inhabited by tens of thousands of people) if sea levels rise. I'm one of them! Now perhaps this proposed regulation is an opportunity for those people, with the population of the other east and west coast states, to get together and save their environment and their homes, and the lungs of everyone from more airbourne pollution.

A post from the Improving It blog

The missing link

I don't know when it happened, but the evolution of building software applications for business, especially those based on business processes and BPM, has led to a missing link. Not a sub-human creature of limited intelligence, although certainly a large gap in knowledge and capabilities inside the teams that define and develop solutions.

Leading a recent business process management project, I ran across this missing link several times. And it has led me to compare the profile of the software projects I was part of maybe ten years ago. Back in the good-ol'-days, software projects seemed to have a nice neat demarcation of roles: the business analyst worked with end-users and management to define the requirements that fed the current needs of the business and the perceived improvements; a software architect worked with the business analyst to translate these requirements into a software architecture of blocks, arrows, UML, and written specifications; finally the developers worked with the architect and (if they were senior and knew how to tie a tie) with the knowledgeable users to work out and eventually code software logic.

With BPM, the missing link has evolved through the pressure of vendors, industry analysts, and probably financial pressure in organizations wanting new software solutions cheaper. The roles have morphed as vendors and analysts tell companies that their business analysts can define and build workable processes without the help of their IT team (although see my post: Your 'Systems Group' is the reason you business teams (are) disintegrated if you want to see why I think that it wouldn't work even if your IT team was involved). The reality is that with the right tools, business analysts can build working processes, though they probably don't want to, because real (rather than just workable) business processes are hard, detailed, time consuming beasts.

So what is the profile of a team in the modern world? A senior business analyst has turned highly strategic (maybe because there is more caché in a hand-waving strategy role?), but still gets his or her hands dirty from time to time defining high level processes using a vague understanding of something BPMN-like. A more junior business analyst takes some of the concepts and tries to make a vague guess of how this maps to the details of the business. The great leveller of industry standards says that if you use BPMN you are sure to get a best practice result (I lie), and then fill in some spreadsheets for the other details you find out along the way that might just be useful. Now throw this information at a consulting firm's expert in your chosen BPM product, telling them that the analysis is complete and there is no room in the budget for further analysis, so just get building. Actually sounds very Dilbert-esqe.

What is happening? The software architect role is the missing link. He or she was carefully superseded by the enforced architecture of the BPM foundation the solution will be built on, forgeting that there was more to the role than blocks and arrows. The business analysts do not really know how to interact with software developers, since their contact has only been with senior strategy people they one day aspire to be, so the level of detail they are able (or willing) to collect is variable. But they try. The consultants are therefore forced to try and meet in the middle by wearing the hats of architect, process analyst, business rules analyst, process designer and software (at least customization and UI) developer. With top quality, highly experienced consultants, there is a good chance that they will fit the gap without a nervous breakdown. For less experienced consultants (or maybe worse, consultants highly experienced in traditional software lifecycles), the gap and constant flux in project requirements, definitions and uncertain rules can be highly jarring.

So, who wants to evolve to be stronger, better, faster, and take some of the traits of the extinct software architect? I don't know - and I'm open to offers from anyone who has seen this pattern in projects or believes that the architecture role is still alive and well. My guess is that the profile of projects I've been involved in has led to the customer not wanting to pay for the people I mentioned: process analysts and business rules analyst. Or maybe there still is a software architect role in BPM under a different name.

Either way, this trend of half-hearted, strategy rather than details-oriented business analysis, coupled with do-it-yourself process developers, seems to present a big risk to BPM projects. There are a limited number of BPM implementation experts out there, so if you want to implement a BPM solution, pick well!

I hope someone can help me with some solid experience, or tell me that consulting firms should stop giving way to clients and force them to pay for more time and resources. Or maybe someone will tell me to pick a different BPM tool that makes analysis, implementation and deployment so easy that the missing link was in fact a natural and necessary part of software evolution.

Comments welcome!

A post from the Improving It blog

Download the podcast of this blog post

Your 'Systems Group' is the reason you business teams (are) disintegrated

One of the big selling points of business process management (BPM) is the way it can provide order to the activities of disparate groups of workers so they can work better and more efficiently. To achieve this, you have to answer the big question 'how did groups that have to work together so closely end up so separated?'. In parts of a businesses that handle customer requests and new accounts (such as insurance underwriting or claims, banking account management, credit card disputes, telco and utilities customer service), it is typical to see separate systems forcing the business groups apart. When groups of users have to operate systems that don't work the same, don't share data and require swivel-chair integration, the way they work together as teams disintegrates.

It is the 'Systems Group' (or groups with other vague technical-ish names) that runs the line of business systems. And it is these owners that perpetuate the separation of business teams by failing to integrate their systems. So it seems obvious where to place the blame - the 'Systems Group'. But it is not their fault.

Repeated observation has shown me that the systems group are experts in what they do: they understand their systems better than anyone. They understand how the systems work, how to keep them working, and how to work around their faults. Because of this they are also often the designers of new 'applications' that fill a need of the business, in the form of Access databases or enormous Excel macros, that further separate and distinguish the roles of individual business users. And they are rarely experts in integration, largely due to the time and patience they must expend on nursing their current systems through another painful situation.

I have a recent example on a project I was leading - I had to teach various highly experienced technical people in the system group about XML, what it was, what it looked like, why it was different from EDI, and how a BPM system could use it to capture data from other systems (including that big Excel spreadsheet that is core to the business). XML is really not that new a concept or technology, but the guys had not had the opportunity to understand it.

With a limited knowledge of the available technologies, and even more limited time to burn, an organization's 'systems group' is not the team to apply to even basic integration tasks. If it was, the integration would have been done already.

So who should do targeted integration associated with BPM projects? That consulting team you have onsite already to build the new BPM solution may cost more than your internal team per hour, and may not be pure software developers, but it is likely that they understand integration mechanisms better than most. And if they represent a decent boutique firm, even if they can't build the integrations themselves they should have access to a team that can. Although it may cost a little more overall, the integration will get done, which is more than can be said for the situation many companies find themselves in currently.

The 'Systems Group' is the reason that your business teams (are) disintegrated. But it is not their fault. So help them improve, the same as you are trying to do with your business processes.

A post from the Improving It blog

Download the podcast of this blog post