Big Data - and what we'll do with it

The Gartner Hype Cycle

Big Data: it is all just hype until the clouds clear, business users can use it, and customers are served better because of it. When Big Data truly arrives as some products in the enterprise, business decisions will start to be based more on information and insight and less on gut feel (by the highest paid person who trumps everybody else). While we are waiting for the final crescendo of hype, I’d like to consider what we are going to do with all that new information.

Most rational people quietly accept that Big Data is mostly hype right now. Everybody is trying to stake a claim to their chunk of it and the chatter on social channels as marketers try to nurture the term into a real market is a source of big data in itself. The concept only starts being real as forward thinking CIOs focus less on the mundane IT networks and PCs and more on helping the business extract value from all the data they have access to using the tools borne of the hype. That is Big Data - the real use of analyzed data to help make business decisions, not just the technology hype about who has the best Hadoop or in memory database. Don’t know what these terms mean? You are a member of 99.999% of the business population, AKA normal people. Because you shouldn't have to know.

We are still in the early phase of the technology cycle for Big Data. The IBMs, SAPs and HPs of the world are still appealing to very early adopters who have money to burn on acronymic technologies that have yet to be formed into meaningful products with advertising friendly names. By 'meaningful', I want to imply that only a small team of consultants are required to install them and make them do something that regular business users and executives can make use of.

Currently most of the focus of the hype and actual product releases seems to be on the storage, manipulation, analysis and visualization of the data. I've seen little meaningful discussion about what I consider key problems:

• making information actionable
• taking business decisions from a concept through actual change
• providing communication and business records without generating a ton of irrelevant email and wasted report writing along the way

This is where business process management (BPM), customer relationship management (CRM), and case management tools come into play. But not as the tech vendors might have you believe. The value is not purely from the extra data they pump into the system from day-to-day management of customer interactions and employee collaboration.

Of course, having a good insight into your customers and business activities is great. Being able to manage the flood of required decisions coming from future Big Data analysis is equally important. How do you actively handle all the business information coming out of the business? Losing it in email is not the answer. Never actually following up with your newly revealed best customers is just a waste.

Handling the flood of new work emanating from real Big Data analysis should not be yet another chore. This is going to be valuable stuff we never had access to before. Managing the work actively through flexible processes, using tools designed to help people follow up on decisions that need to be made, this is a key component of Big Data. Its not currently the sexy part (for geeks at least). But it is the final component that ensures that all the investment in technology, analysis and experience is not just lost into meaningless email conversations that go nowhere.

Speaking of conversations going nowhere... follow me @consected on Twitter

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Automation, BPM, ethics and competition. Or serving customers better.

A recent discussion on the ebizQ Business Process Management forum asks: “what percentage of processes should be automated?”. In any given company, how many of those routine processes that get work done should be taken largely out of the hands of employees and made into software, or painstaking converted into automated manufacturing production lines? An interesting response came back came back from Emiel Kelly on the ethical implications of full automation. What happens to all the human-beings that previously had jobs and have now been phased out? This is not new news, but it did touch a nerve for me, as I was just reading George Orwell’s 1984, filling the huge gaps in my school history classes with some time skim-reading Wikipedia about Marx, and thinking how to avoid the “race to the bottom” in the world of software development as the low-cost offshore talent pool continually grows.

So, is there an ethical issue to automating business processes that can be fairly automated? The question is perhaps, “who benefits from business processes being automated?”. Should an organization be holding back improving its products and services, and providing a better customer experience because it is afraid of the moral implications of significant organizational changes? Or is it just hoping to cut costs to be more profitable and serve shareholders with larger dividends? Really the ethics of a corporation are guided by its own policies and mission statement, within the very loose boundaries of the law. If corporate governance suggests “employees first” then it can have an ethical issue with large scale automation.

The reality of the situation is that automation of processes and using BPM to reduce waste and improve efficiency are not big evil entities, out to strip every experienced employee of his or her pride. If BPM doesn’t improve the way a business performs and serves its customers, competitors in the marketplace will certainly ensure that hard working people in an 'overly' ethical company lose their jobs. Or those competitors will force that company into a position where business process outsourcing or offshore manufacturing become the only option. From the standpoint of supporting the local population with employment, outsourcing is no better when it comes to your complex ethical quandary.

Companies have to decide for themselves the right balance between:

• responsibility to their local labor-forces as potential employers of people
• responsibility to existing employees providing value to the company
• responsibility to shareholders to ensure continued investment to operate and improve
• responsibility to customers to meet obligations and attract new customers.

At the end of the day, the majority of people want a secure job for a secure wage. Free-market economics, the social safety net, government (big or small) and technology all have a part to play in meeting the needs of the local population. There is no easy answer. But you can guarantee that by avoiding automation and organizational change for fear of facing such ethical issues, a more ruthless competitor will walk in and still serve what were previously your customers better than you can. A company remains in no position to employ people when it has no customers.

Automation and BPM can help a company advance to serve customers better, at a lower cost. This subsequently ensures the ability to survive, thrive, innovate and subsequently employ a greater number of local people.

Chat with @consected on Twitter if you think I'm missing the point. 

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Methodology does not trump human nature

Methodology. An ugly word. When used alongside business process improvement, 'methodology' suggests that there is a logical approach, a preordained series of steps, a pretentious way of saying there is a method to fixing business process problems. Like a workflow for fixing your workflows. At a high level, I’ll concede that this may be reasonable, but get much deeper than “analyze, measure, improve, rinse and repeat” and the methodology is just a hack of a bunch of experience and skills (I hear the Six Sigma guys beating at my door already). A methodology when used without care can blatantly ignore human nature, organizational behavior, and sheer common sense. I prefer my methodology to be more a constructive generic framework.

Things get even worse when the eventual goal is a strictly defined, no nonsense Business Process Model and Notation (BPMN) map of the process. Any graphical notation for drawing ‘workflows’ that requires a 538 page PDF specification probably needs the support of an equivalently strict methodology so its developers don’t stray off too far from some form of best practice in drawing their pretty workflow diagram.

As we all know, there are many ways to actually handle the implementation of business process improvement projects:

• a business process management (BPM) tool to implement the workflow
• a suite of tools to draw, develop and analyze the processes
• a bunch of offshore software developers to produce some vaguely usable services for end-users
• some common sense guidelines for workers to help them guide the process better themselves
• any combination of the above

The reality of many successful business process improvement projects, independent of the implementation approach, is that the more methodology you try and stuff into the analysis and development of the ‘solution’ to your problems, the less room there is to maneuver when it comes to the actual reality of business processes: human nature and company politics trumps everything.

My proven approach (call it a methodology if you must) to business process improvement projects, (whether they depend on software development, business process management (BPM) tools, or plain simple task lists) is simple:

flexibility, iteration and communication

I unfortunately haven’t had the pleasure of re-engineering a process of 15,000 people, which likely requires some significant structure to making it all work. My experience is more for the 15 to 150 people processes, and to do them well often requires less methodology and more flexibility.

Think I'm completely wrong? Follow @consected on twitter and tell me!

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Business excellence - how do you know you've got it?

There is a concept of 'excellence' that is often used in business improvement to show that we are doing something so well that everybody agrees that we are excelling at it. On the BPM ebizQ forum this morning, the question came up of what is process excellence, and what is a key metric to show it?

A great response from Steve Weissman sums up the difficulty of measuring any form of excellence:

It's sort of like pornography in that – as Supreme Court Associate Justice Potter Stewart famously once wrote – it's hard to define but "I know it when I see it."

My thinking was along similar lines, that excellence is hard to measure but easy to know when you observe it working in practice:

I'll suggest that process excellence is an emotional response to a process or set of processes. "Happiness" could be the very untechnical metric.

If everybody is truly "happy" with an organization's processes, there is a good chance they are excellent. When we don't have process excellence, it is hard to measure but easy to observe: users don't fully adopt them and there is rarely additional investment.

As with anything we do in business, happiness with processes just means that they are delivering the results that everybody wants without getting in the way. So maybe I could have suggested an even better non-metric to define business or process excellence:

If you don't notice that you are performing a process or activity because it is so easy and natural, and it has the desired results every time, you have probably achieved excellence,

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Why bother with DIY BPM?

Companies that have tried improving their business processes, either through manual improvements or software BPM solutions, know that the DIY approach can be a big time-suck. So why bother? Everybody looks at the return on investment in projects based on hard costs, and the costs with in-house software are never small. But few people look at the costs on your time, the business person who desperately wants things to change, but can not spare the time to think about things deeply enough to make the changes useful rather than plain damaging.

I've been chatting with Ian Lever at Forward Look about alternatives to IT-centric BPM tools for business improvement. To steal one of his thoughts: why would you invest in building a leave/vacation request process, a travel expense process or a time sheet system using internal IT and business users, when there are a hundred low cost, ready made alternatives out there already? For many large companies, it seems easier to call the ERP vendor and have them enable the module and customize it to your needs (for tens of thousands of consulting and licensing costs), rather than suffer the indignity of going online and signing up for an easy to use system that doesn't really integrate  (but doesn't need to) to your ERP. Burn some IT budget and get something in six months, that's the only way to go for many locked in by their IT department. For the rest of us, where that one project spend like this would exceed the annual IT budget, build versus buy becomes a big question. Doing it yourself is not always the cheapest way to achieve the goals, and unless you are really handy with the tools it is rarely going to achieve the highest quality result.

For this reason, software as a service (SaaS) vendors exist to deliver solutions for what you need. This isn't like the BPM vendors and their 'templates'. This is real running solutions, ready to go. For this reason, Consected will be announcing some new Instant Apps. Look out for these new, free and low-cost apps at Consected Instant Apps.

"Great!", you say, "but nobody does what I want, my way". Well, if you really have faced that problem with the lack of appropriate SaaS solutions for you specific business need, add a comment below or contact me (select 'customer service', since I'm not in sales mode), and share your ideas, wishes or gripes with me. A problem shared... 

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

The value chain doesn't have to be linear

Porter Value Chain (from Wikipedia)

Working with clients face-to-face is always interesting and enlightening. However much a company may need help from a consultant in a specific area of their business, the consultant always learns a new way of looking at business problems. For me, a recent trip to a client led to many discussions about strategies for improving the business, both the little things and the big things. The big things, such as M&A and moving to a new headquarters, often have the greatest payback, but in terms of looking at the day to day operations of the business, looking at how a firm can improve its customer service quality while reducing wasteful activities can also pay back big.

During my visit, we started discussions about the value chain. We envisioned a long paper chart, pinned to the office wall, showing everything from prior to attracting a new prospective customer to the business, through serving them successfully and profitably, to finally ending the relationship and eventually dissolving that closed account completely. Its a compelling visual, since it touches so many pieces of the business, and can help business people who have become so entrenched in their piece of the puzzle to look around and see how their work impacts others, both positively and negatively. This long value chain / enterprise business process will make a great project for somebody, one day.

The issue I have whenever I look at the value chain, is that it is often viewed as a fairly linear and blocky thing, showing a flow of activities leading to value at the far end. Maybe this is just because many examples focus on manufacturing and the success of production lines. Of course outside of a production line, we all know that this linear view is just not the case. Activities go on in all areas of the business that deliver value, and different departments aren't always as remote from the action as the Porter Value Chain diagram (above) would suggest. Especially in services industries, I would suggest that we would end up with a series of segments of an orange all pointing in to value generation in the center. After all, it is hard to say whether a client will be more upset about a screw up in one group or another, when the financial outcome is about the same. In financial services, if a firm delays a wire transfer for $100k, or a rep delays placing a securities trade that increases the individual's risk, the actual cost may be small, but the perception from the client may be huge. Finance was responsible for one error, sales for the other, and only an orange slice view of the value chain puts them on equal footing. Reversing the view and delivering top quality service in both areas of the business may also deliver equal financial and value to the customer and then back to the business.

The issue with all of this is that the orange slice view of value does not help people understand the business processes that are being performed. It highlights that we are all one "big happy team", but in terms of understanding, it shows little else that is tangible to a business person. So the value chain can not replace business process definitions, which show the way work related specific transactions flow through the organization. And business processes rarely show where the valuable work is done in the organization, just showing where work gets done in an overall timeline. So my reminder to myself as a consultant is this: "just because I can make a business process work better, I must look at the value chain to understand where to focus my efforts". Nothing new, but a good reminder to all of us to get out out the weeds and look at the orange. And when things start getting a little too high-level-strategic with little focus, I can alway dive back to fixing specific business processes that I've now shown will deliver value to the business, and importantly its customers.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Fix the little things, and get big results

Workflows are just not big enough for us to pay attention to any more. Why bother fixing things that just involve a handful of people working to get a job done?!

Most business process practitioners experienced the days when a business process was represented in reality by a paper workflow. The movement of work from one person to another represented the process for specific work to get done, so we called it 'workflow'. The word workflow seems dated. Despite this, the paper workflow still exists, although in many cases the workflow has become email based, with just a piece of paper to be signed by the customer. 

Business process management, both methodology and technology decided along the way that it needed a bigger piece of the pie. If you just transfer work from one place to another, surely that's not very exciting. Every professional needs more than that. Let's make sure we can measure the process in a way that was never needed before, analyzing it to a level of detail that could be considered obsessive. Let's model a new improved process and simulate its inside workings so there are no surprises. Let's step it up another notch and implement the new process with tools that could run real-time stock trading.

None of this stuff is bad, just for many organizations (okay, all organizations), there are simple workflows that are run on paper or email. They don't need much analysis and they don't need simulation. They certainly don't need a 6-digit piece of software to run them. These workflows are common: accounts payable, check/cheque requisitions, complaints handling. Business process management wants to think big and be big. So nobody ever focuses on the fact that some of these processes have an impact through the value chain on customer satisfaction. 

So while we are trying to fix business processes at an enterprise level, don't forget fixing business processes, oh hell, call them what they are, WORKFLOWS, at the departmental and team level. Its amazing (although it shouldn't be) how picking off some of these smaller items can help a company be significantly more profitable through better customer service.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

What? Not Collaboration?

Anybody who has read my posts for a while will know that I have big stretches where I post nothing. Looking back,you can see my blogging rate follows a pattern: it starts solidly, maintains itself well, before building a crescendo (of quantity or quality) and then fizzles out pretty fast to a long period of silence. Since I'm not communicating with the outside world through my blog, nobody will really know why this is. Well, its two word that don't really fit together neatly: "relationships" and "process".

Social networking and everything "Web" has tried to teach us that you can maintain meaningful relationships online, with people you've never met and are never likely to meet. That's fine, and I won't deny that there are names I recognize on screen that I have discussed matters with that I would never have known in a past life. I work from a home office, so I understand completely the importance of online communications. Hey, I even can enjoy chatting to people on the phone if its somebody I genuinely like. But its never quite the same as "face time".

This is why my blogging pattern is erratic. I work hard for clients because I like them, or grow to like them. But its like having a new best friend, it tends to exclude others for a while. Now with a client, the relationship is kinda weird - its a big love-fest with multiple people AND a project, all in a big boardroom. I suppose I'm a geek at heart. I enjoy technology and I enjoy seeing how businesses work. But I have come to realize what I enjoy from it is seeing how people respond to the technology and how they interact with each other to achieve their daily work. I genuinely want to make it better for everybody. That is why I like business process management. What? Not collaboration?

Business process management is great, as it addresses the fact that in business processes you are trying to force people to do what comes naturally to only a few: work together smoothly, efficiently and consistently in a fairly alien set of activities (if you are telling me that most of the work we do in offices is natural evolved behavior I'd probably not believe you, therefore its alien). If you can help people work in a structured way for work needing that structure, the end result can be quite impressive. I've seen customers' employees just glowing with excitement and happiness that so many of the stupid annoyance of their working lives have been removed. This isn't collaboration. Collaboration let's people do something that is natural (work together in unstructured interactions), doing it better when it comes to information sharing. Its great and useful, but its a different animal.

My reason for not blogging and chatting with some of you recently? I've been helping a client deliver three business improvement projects simultaneously. One is a big catalyst for many other business changes going forward. I have a relationship with the people around the project and the project itself. And when a just bit more process improvement is eeked out of it, I'll be very happy and blogging again with great gusto! My new best friend will have a great process. And great processes make everybody happy.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Old approaches to business process management are failing companies

We all know that companies of all sizes are facing tough economic challenges at the moment. These challenges are coming from one of the toughest directions possible: customers are not spending money, making it more important than ever to convert the few available prospects into profitable customers. Improving business processes is a powerful way for companies to work better, but the old business process management (BPM) approaches companies often rely on just don't fit the current challenges.

Companies invest in business process management from two direction:

• methodology - the way a company can fix its problems
• technology - applications helping people work in a more structured way

The reasons for doing this were all reasonable in an economy with plenty customers with cash in their pockets:

• reduce headcount
• do more work with the same resources
• improve the quality of a product or service

In the current economy, these types of improvement are not enough. Whether a company is a bank, a manufacturer or a law firm, the challenges facing the business is that the economy is making it harder to attract new customers and retain them.

This is where modern business process management solutions kick in. First, they offer a faster startup time with more focused analysis of problems, which means less money is spent on teams of expensive consultants trying to build strategies for things that don't matter. Second, the solutions offered already include a range of business templates, helping companies to build to a tried and trusted plan rather than always reinventing the wheel. Finally, and possibly most importantly, the methodology focuses on iterative improvement, rather than trying to get every little thing right first time. When the tools are designed to adapt to this types of constant change, the company can improve based on experience rather than luck.

With this lightweight approach to business process improvement, the flexibility to change processes based on experience and best-practices allows companies to do something that in the past was really difficult: 

• treat each customer as an individual rather than force fitting them into a standard model of a customer
• allow the processes that serve customers to extend and adapt based on circumstances
• help the business owners introduce new improved processes rapidly and with minimal cost

Business process management can help companies meet the challenges of the current economy. Companies that adopt new methodologies and technologies can become known for great customer service at a good price. In these times when social media is the marketing machine, and word of mouth spreads corporate reputation like wildfire, companies can attract and retain more customers than ever before.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

When documents and processes come together

I'll admit that the coming-together of processes and documents (BPM+ECM) has been a common theme of this blog for the four years that I've been spouting-off here. My background was imaging and workflow, then I got trapped along the way in understanding records management and even more trapped when process improvement became BPM suites, and more about the process than the stuff in it. I can not avoid feeling that I've heard this all before, but still wasn't satisfied.

Yesterday, a forum on ebizQ brought together some of the opinions about the question "Is it inevitable that BPM and ECM will be integrated into one system in the future?". For companies running both of these technologies in house, the answer is probably a no-brainer. ECM and BPM are already integrated, because the customer did it themselves. For vendors, nobody has worked out really if they can make money from it.

I've included some quotes from the forum that I think sum up the range of opinions, though its worth reading through the whole thing if this topic interests you:

Ian Gotts of Nimus: "The two are inextricably linked already. If I want to perform some task such as sign off a PO then I probably need to access the Purchase Policy document which will be part of ECM."

Malcolm Ross of Appian: "There's a definite need to unite the features of these two worlds to create more powerful content and process systems."

Doug Mow of Virtusa: "From the customer, patient, subscriber or end user perspective I want a seamless UI that doesn't distinguish between any class of functions. "

Brian Reale of ProcessMaker: "It is one thing to route a document or a PO, add a signature, and then store it in a DMS. It is another thing to start a process in a rich contextual environment and have that environment intelligently populate with the pertinent information based on attributes like user, place, time, and company policies. "

Peter Evans-Greenwood: What's a document/record anyway? A page in a wiki? An email? SMS? A tweet? Defining the scope of BPM and ECM as processes and documents ignores the ongoing erosion of boundaries between organisations and communications channels, and existing solutions are too intrusive to push into these new channels. 

I'll quote my own response in full:

The short answer is this: in any business that uses BPM in critical applications, BPM is already integrated with ECM. I think it unlikely that we'll see anyone but IBM and maybe EMC really producing a credible E-BP-CM suite. 

Why do I believe this? Well, its important to ask why ECM is so important to businesses... Its not the collaborative-Sharepoint-less, "let's be happy and work together" stuff. Its the fact that in real business, at the end of everything we do in a business process there needs to a record of the transaction, the decisions or whatever that formed the outcome. Of course, that does not need ECM if the data we were work with at every step was fully structured (an online form producing structured database records). But for the real world, documents do exist, and ECM provides a way to handle them. 

As Doug says we must interact with documents, and as the vendors hinted, document management ain't that hard for BPM vendors. The problem is that throughout a process, documents will form part of the final business record. BPM vendors rarely manage to focus on understanding the complexities of electronic document and records management, therefore they rarely do much more than routing documents -- plain old-fashioned 'imaging and workflow'. 

What is really needed from BPM is a final step: registering the records and the decisions of the process in the corporate records management system, keeping the context of everything that was done. Working with documents and process context appears in some of the marketing around case management. Though more often than not people get more excited about how processes can change dynamically, than how they can be recorded permanently. So I expect adaptive case management (ACM) to be another missed opportunity. 

It really is a shame that records management has such a 'stodgy' appearance, since it is such an important part of business processes.

This is one of those tough areas where the integration of technology for vendor gain often eclipses the needs of the end customer. Careful consideration is required on what is needed for any particular business, and navigating the options depends largely on experience.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Cases crystallize out of chaos

Coming via the bp3 blog by Scott Francis, Frank Micheal Kraft talks about Patterns of Knowledge Work. His discussion hits the point that many activities performed that are not 'production line' processes are really based on the activities of a knowledge worker: a person who is knowledgeable about what they do, and builds up structures around their work to keep stuff organized.

This ties into my discussion a week or two back that in my own client work, I've started to see how I can examine the records of business activities, the documents and paper reports, and track back through them. In doing so I build up a view of where the major business processes in an organization live, who does them, and at a high level at least, what the activities performed are. Amazingly, the often overlooked org chart helps me in seeing order in the chaos. It is interesting to me to see that there is a natural order to processes and information in business.

For Kraft, he talks about the three ideas he has come across:

1. 
   

   Managing my own knowledge work. As I wrote my own Adaptive Case Management system for my own knowledge work, I was able to organize my own work. As the number of cases increase – 3000 now including sub-cases – I become aware of patterns.

2. 
   

   Feedback from my first pilot. This was very interesting, because the main focus for my pilot is usability. Usability is strongly interwoven with these patterns of knowledge work.

3. 
   

   The things I always wanted to model, but never was able to. I governed the modeling of thousands of models of structured processes from all areas of business processes. But because the modeling language was only able to model predictable processes, I never was able to model unpredictable processes.

In my view, he has done with these three points what many business people have had to do -- build a mechanism for structuring his own work in a way that allows him to be productive and get value out of work he has done before. For many people, this is a matter of building a filing system, putting together checklists and tasklists, maybe even putting together an Access database recording people or indexing their files. Oh that, and never going on vacation, as nobody else can quickly pick up the structure and work with it.

Kraft has written his own Adaptive Case Management system, probably because he felt he could put some structure around the work he was doing, and that structure was adaptable enough to help others in their own work. With my own consulting and software work I have done a similar thing. And as Kraft says: "As with all knowledge work the result of my effort is not completely predictable. But I am making good progress.". 

I couldn't agree more. And with every new client or process I hit, more structure and flexibility crystallizes into something that benefits the next client down the line.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

'I hate working with documents on-screen', and other issues we reinforce

You've heard the phrase "Knowledge is Power". There seems to be a human character trait that says by keeping documents close at hand, preferably within steps of my office chair, I am more powerful. Filing cabinets for individuals, and "working copies" of client files are everywhere in offices. Take that easy access to information away and people fight back. You are removing some of their ability to hoard information, all of which is a duplicate of something available elsewhere, but it exposes a frailty that leaves them uncomfortable. "What if somebody else has the file the one time in a million I actually need it?", or, "What if I'm caught off-guard, a client calls and I don't have their information to hand?". This is just one of the ways employees resist the introduction of enterprise content management (ECM), case management and business process management (BPM) solutions that try to limit the amount of paper moving and filed in the organization.

I have had the 'exciting' opportunity to spend some time working with lawyers over the last couple of years. From helping smooth immigration paperwork to cleaning up company contracts, it doesn't seem to matter who I work with I experience the same thing: paper. When it comes to the workings of a law office, I am frustrated by the apparent waste of paper (and the subsequent charges for photocopying applied to my account). When I think about it though, the issue is obvious with a lawyer because the multiple copies of documents happens typically right in front of you, while you're sitting there in the office. Although not so obvious, regular offices experience the same issue. Most of us I'm sure have seen the pervasive footer on emails, "Do you really need to print this email?". There is no way to know how much paper is wasted on unnecessary printing and copying in offices, because it is not charged per page.

For the 14 years I've been working with electronic imaging technologies, I've always encountered the concern that it is hard to work with text on a screen, but early on companies worked hard to limit the concerns of employees. In the UK at least, as a user of a screen and keyboard, an employer was required to ensure your working area was set up to avoid discomfort and to improve your posture. Companies investing in document imaging put in place minimum specifications for screens, and usability requirements for applications to make it easier and more productive for people to work without paper. These lucky people of the 90's working with electronic documents had it good.

Now when I visit clients, it is not unusual to see LCD monitors in every cube. Screen technology has progressed to a level where great quality should be available on every desk, but we have instilled the concept in the heads of employees that it is hard to work with documents on screen.  Why, beyond an aversion to change, does this persist?

I think that the problem comes not from the screen, but from the documents. Many regular people think of Word documents when reading on screen. Word is an editor, not a document viewer, and it does a terrible job of making documents easy to read. People remember this. Adobe Viewer for PDFs presents nicely prepared documents beautifully. But so often we end up reading marketing brochures prepared in multiple columns for glossy printing, needing to scroll around with every paragraph read, that we learn to hate it. The same with the trend to scan documents to PDF. The viewer does a generally poor job of making scanned documents appear attractive and clean.

My feeling is that companies wanting to become more paperless need to concentrate on the underlying issues of the documents they try and have people use. If your scanned documents look ugly on screen, people won't want to use them. If you force people to use daily reports by scrolling around left, right, up and down, they complain of RSI and general reduced performance. If you archive Word documents for constant reference and record-keeping you're asking for trouble in so many ways. As an aside, I saw a Word document archived in a large government agency that was unreadable, because the pretty font used by individuals was no longer available. This applied to thousands of documents.

Maybe it is time for companies to focus on how they can make the information that gives people the power to make good decisions not only available, but easy to use. This isn't just document scanning. Good application design and recognizing that people want to organize information their way will help people work better. Companies need to focus their investments in document management, business process management, and case management on making users actually want to use the new applications, since this desire to use the application is so important to getting paper off everybody's desk.

A post from the Improving It blog

Pigeon-holes are for the successful

Unfortunately this 'fun' discussion wasn't as a result of something I blogged, but its worth a look. According to Adam Deane:

My view is that Case Management should be implemented by ECM vendors, not BPM vendors.
Case Management revolves around data, documents and data therefore should be dealt by ECM professionals.
ECM requires a different set of skills than BPM.
It would be in the customer’s best interests to have separate systems for BPM and ECM.

I personally believe that it doesn't matter where Case Management sits. Its the business value that this type of solution can bring to businesses that is important. And until my business, or somebody else's is as synonymous with the that specific category of solution as SAP is with ERP, we all need to just accept that the industry is a bunch of pigeon-holes.

Follow along with the comments on Adam Deane's blog. Its getting fun...

A post from the Improving It blog

You are nothing without a public API

I am going to build an API. Who wants to help me shape it? After all, every self-respecting web 2.0 service has an API. And my self-respecting web 2.0 service wants to be the best platform in the cloud for developers to build super-profitable applications.

For those of you who aren't familiar with the concept of an API on a web-based service (for those of you that are, bear with me) the API is like Lego for geeks - it gives smart developers with a wish to "get rich quick" the opportunity to build out their killer-app, using the building blocks of an application that already has done some of the grunt work for them. This isn't just a way for developers to leach off the hard work of others. Its really about a service being able to bring in smart, innovative individuals, at minimal cost, and in return for the talent and ideas they put into building applications around your service you take much of the mundane stuff out of the picture for them. Innovation can thrive and isn't stifled by maintaining servers, doing backups, or building login and security. And both developers and service providers make sure that there is a way they can make a good healthy profit if one or other sells the new application.

APIs are great if the service that you build on hits one of two criteria:

1. It is so successful that you stand a chance of picking up some of the available market of 50 million people using it
2. It is so useful and makes the development of your applications so much faster that your app can offer real business benefits

As I have been looking at SaaS/cloud-based business process management (BPM) and workflow tools, none seem to offer a truly open API, allowing developers to hack together whatever they need to around the central core to get to the application that they desire. Why is this?

BPM tools have come from the enterprise software school of thought. You install one in house, spend thousands of dollars on training, build an application for a department, then wait for IT and the business to find the budget to repeat. Software as a Service BPM / workflow offerings (Consected is one, although there are a handful of others) take the grunt work out of putting a new workflow system in place. We handle the servers, the backups, security, etc. We also have to make the configuration far easier than our enterprise software grand-parents, as we're not going to be able to attract people with a 10k price tag for training. This can make some of the flexibility at times a little limited...

So this is where the API comes into play. The underlying capabilities of a service such as Consected really help developers build applications faster. Sure, they're probably not building another FriendTweeter, or whatever, but if there is a real business problem out there that they see companies have, and some smart hackers have never really found the tool they want to build it on, this is a great option. SaaS BPM gives a developer this great stuff:

• Workflow - real, structured workflow, tracking work as it flows through a series (possibly very long) of activities performed by people
• Task tracking - allowing simple ad-hoc tasks to be created, delivered to users and tracked through time
• Structure - an obvious way of structuring applications where work or activities performed by one or many people fit together really easily
• Notification - configuration by users of how they want to be informed about work targeted at them
• Search - ensuring that work you create can be found
• Storage - of data, documents and related information
• UI - yeah, you don't necessarily want to have to build all the stuff that's been done before, just build on it
• Security - authentication, authorization, roles, audit, user and password management, etc

Consected has an API today. But I think that it could be better. The underlying service works great, and is fast to build applications on. But developers are what make services in the cloud successful. And how often as a developer do you get to shout out your ideas and have someone put them in place for you, so you can get on with building your killer app?

If you'd like to see how Consected can take the dull work out of your next killer app while giving you the chance to create the API and platform of your dreams to build on, take a look at the website (its a bit corporate, I know), contact me (phil.ayres at consected dot com, twitter.com/consected, etc), leave a comment on the blog, or even pick up the phone and give me a call.

We are open to ideas for us to have fun building applications, get noticed, and hopefully make a bit of money too!

A post from the Improving It blog

I am a client, not a case folder

Over on Redux, Tom Shepherd talks about Case Management, and how the WfMC (Workflow Management Coalition for people outside the industry) is attempting to put some relevant thoughts around the non-workflow aspects of business processes. There have been many attempts at defining what Case Management is, and I don't care to write yet another one - I've blogged enough times before and frankly nobody cared then either!.

An important point for case management is the case folder. Okay, so this is the core differentiation of the product that Tom manages, and what allows it to call itself a case mysanagement product, rather than an imaging and workflow (document-centric BPM, in industry lingo) product. Its a great product - from a consulting side, I managed the implementation of an insurance underwriting and policy management solution based on it in under three months with just a few pains and late nights along the way. But aside from the product, is the case folder concept really anything special?

The problem for all product vendors is that they need a name for each feature of their product. Especially with business process management, the business problems that you can solve with a product are often so broad and unrelated that trying to give a piece of functionality a name that is meaningful to a business person just pigeon-holes it into one industry. That is the problem with the case folder - it is meaningless to a business person, but its virtually impossible to find a name that is more useful.

I've seen case folder concepts from multiple software vendors - hell, Consected has its own take on the concept (though it borrows none of the intellectual property from Tom's product, or the Tower/Vignette/OpenText product I worked with previously, before random corporate organizations with no better way of generating income start trying to make my life miserable). The approach I take though is this: to assume nothing about the case folder up front, beyond the fact that it is a way of representing business information or entities (a client, an insurance claim, a 'know your customer' (KYC) bank application review, an invoice, an employee, an account, a securities trade). A 'case folder' may or may not have structured database-style information. It may or may not have documents associated with it. It may or may not capture comments or discussions from users. It may or may not sit inside or contain workflows. It may or may not have checkbox tasks, deadlines or whatever. It may or may not be related to other business entities.

Most businesses don't get what a case folder is. Trying to beat them over the head to understand the term, just to make it easier for vendors to sell them software is not really the best approach (in my opinion). If we sell solutions, we conveniently forget the functionality and buzzwords of our software, and instead pick up the needs and buzzwords of the industry we are working with.

So, I agree that information, processes and 'case folders' must work together sometimes, standalone sometime, and not exist at all many times. The name and the functionality of a particular vendor's manila folder approach to organizing information does not interest me or the business I'm working with. As a business user, what matters to me is the 'something' I'm working with. Businesses benefit from focusing on their customers, as much as software vendors do, and helping them do that by putting a 'client' not a 'case folder' in front of users is a huge benefit in a solution.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Improving processes as companies merge

Mergers and acquisitions can lead to chaos at the best of times, with inconsistent processes and un-integrated teams. Can business process management (BPM) or general workflow automation help in M&A related organizational integrations, or is it just money being thrown into an inferno of change?

BPM marketing often uses words like 'agility' when describing how your processes can be adapted to respond to change. Agility implies an ability to dodge new requirements and keep ahead of the chasing threats, all requiring constant attention from Management to work. I prefer a process improvement solution that is 'flexible' and can absorb the impact of unexpected actions and requirements, automatically taking on the new shape required by a rapidly changing organization.

In a chaotic organization, there is the temptation to avoid process improvement, since it is too much to handle and things are changing too fast. Despite this, bringing structure to the processes that enable a company to operate is essential, whether there is chaos surrounding them or not. With a strong starting point, a department can not only run its own operations better, it can start to influence the organizations with which it interacts. In an M&A scenario, having a solid base of process can make it more appealing to retain that backbone of operations in the new organization, rather than defaulting to the typical political decisions for what stays and what goes.

The problem is that traditional BPM takes a significant time and investment to implement, which is rarely a possibility when approaching M&A. A better approach may be instead to consider a 'quick and dirty' fix to the key processes that will be interacting with the new organization, in the knowledge that everything will change anyway. To be successful, the 'quick and dirty' approach needs to also be flexible (that word again), to adapt to the constant change around it, rather than just collapsing by being too brittle.

Picking the right technical products to build your solution is one part of it. Collaborative technologies, like wikis are great for sharing information in a loose team with minimal effort, but they don't help reinforce processes that require repeatable operations and decisions. Business rules management may be better for processes that rely on complex decisions that must evolve over time, where the end-to-end process is limited in length. BPM is fine where there is rigidity and constant repeatability required and you have time to put it together. Software as a Service (SaaS) or prebuilt solutions running in the cloud can help to get things up and running faster.

I think that companies need a combination of all of these, even when they are not in the chaos of M&A. And rapidly built solutions using flexible blended applications may not be a bad approach to follow.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Lean + BPM = no big surprise

As I have been working more with process improvement professionals that practice lean methodologies, I thought I would put down my thoughts on what 'lean' means to the office / services companies that are typically customers of business process management (BPM) tools. I'm sure for anyone involved in 'lean' already this will sound like a very rudimentary definition; for that I apologize. This is really an attempt to try and communicate the value of applying lean manufacturing techniques to BPM projects, for customers that have not yet delved into one or the other. To me it seems that the combination of lean and BPM is really nothing new.

Lean Production / Lean Manufacturing has been refined by manufacturing companies, building on decades of experience running ever more efficient production-lines. Without the constraints of a physical production-line, office and services businesses often struggle with improving their business processes, typically falling into the trap of deploying ever more complex enterprise software. The benefits of lean methodologies can be experienced by businesses without a huge software investment and lengthy implementation projects; of course, a solution is required to help guide work as it flows between the activities performed by different people in an end-to-end business process.

As some vendors start marketing the benefits of Lean Business Process Management (Lean-BPM), it is important to remember that the design of new and improved processes with BPM and workflow tools has always incorporated aspects of lean methodologies:

Remove waste from the process

• convert manual delivery of paper documents to automated delivery of electronic work cases
• prevent repetitive email of requests lacking appropriate information to template work requests guiding the entry of all information
• handle manual allocation of work by supervisors to team members automatically, allowing supervisors to focus on delivering value as experts rather than task-masters
• reduce the time-lag between activities especially for priority work, by instantaneous delivery of work to the next available person in the process, allowing a critical series of activities to be completed faster
• remove the need for rework by implementing solutions that guide people to completing their tasks correctly first time, also improving quality of the work product and customer perception

Continuous improvement

• provide the capability to measure the performance of processes with real business metrics
• identify issues and areas of waste in a business process with easily reviewed information
• allow business users and analysts to make changes to a process without burdening IT or requiring software development skills

Lean-BPM is a marketing term, not a standalone methodology. A company almost certainly needs software to help improve an office- or services-based business process. If you follow the advice of experienced lean practitioners you will avoid committing to over-complex BPM and enterprise software tools and their extensive software projects at the outset, until you have a better idea of whether they will offer real business value to your to-be processes.

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

Onshoring needs supporting too

There is a big push around onshoring - the term applied to pushing out parts of your business operations to locations that are often considered more cost effective, while avoiding the difficulties of locating services overseas. The McKinsey quarterly targets onshoring in the following way:

The advantages of staying onshore are greatest for a company with products that are not labor intensive, have short life cycles and high obsolescence costs, and target very time-sensitive customers.

The reality of onshoring is that it needs the same level of technology support, if not more, as offshoring operations. Of course, there is not the complexity of dealing with the local cultures and politics of a far off nation to deal with, but as McKinsey puts it, the benefit of onshore comes with time-sensitive customers. Only if you can ensure the premium customer service reps, the expert technical support staff or the fashion designers have all the information to hand that they need, and can communicate effectively with the rest of the company, can you ensure that your onshore operations will deliver the real-time, local timezone value that you are aiming for.

One big complexity for organizations is not in sharing their customer data (CRM is normally available) or communicating in an ad-hoc manner (email and phones are pervasive). The issues come typically from assigning work, handling and tracking correspondence received in disparate locations, sharing documents, and keeping visibility of performance. Without some form of work management, business process management, document management, collaboration or case management, it is virtually impossible to ensure that the remote locations (potentially multiple onshore offices and your HQ) are sharing information and tracking work effectively.

Any one solution is not necessarily the right way to go, but it should be a relatively easy task for a business improvement specialist to look at an organization and identify how improvements can be made, both in process and technology. Attempting to use people with only an internal world-view may limit the options presented, just due to the obvious risk that comes with going against the status quo. At the same time, you shouldn't always need a team of McKinsey consultants to tell you that an office in another state needs to communicate with your HQ through a series of fairly easy to identify, and implement ways.

A post from the Improving It blog

To implement workflow and process automation in your business today, visit www.consected.com

Classification of documents and processes

"Everybody focuses on document classification, but nobody ever talks about how to classify business processes. WTF?" - the considerably sanitized question I received from a client this week. Its an interesting one that maybe I will change to "How should a business align the classification of its business processes with the documents and records generated and captured within those processes?".

Back a few years, when this blog was new(er) and I had the energy to be putting some interesting thinking into writing posts with uncatchy titles, I wrote about the converging classification schemes of documents and records. This discussed how the formal taxonomies and fileplans of corporate records management might start to align in a meaningful way with the full-text indexing (Google-style search), tagging (at the time Technorati, now every blogging and bookmarking tool out there), relational databases 'indexes or titles' and a bunch of other ideas for identifying information. The conclusion was that they need to, since all these approaches have value. The cost of doing so for a business can be enormous, since adding this information can be labor-intensive.

Now add the question from my friendly client, and not only do you need to work out the meaning of corporate information, you may also need to classify the business process that produced it. The question is, if I really do go about filing documents in a structured filing system, should that be based on the content of the document, the way we need to retain and eventually dispose of the documents, the business process that produced it, the arrangement of processes documented within a COBIT structure for SOX, or some other classification that only a highly paid expert could imagine?

There are many arguments for many different approaches. We already have file plans for organizations that need to manage their formal records - the EPA for example talks about its file plan in decent depth, and how mere mortals can build on the fundamental structure within their part of the business. The focus with the EPA's guidance is to organize the records into something that allows the information to be found in the future, the security requirements and the need to archive long-term or destroy the documents according to a schedule. I don't see much business process in this.

In my opinion, a well thought out plan for storing your documents and business records automatically includes the business process that generated the information, but only if it is valuable to do so. A simplistic example based on an insurance company, could put records into this type of classification:

-> Line of business
-----> Customer
----------> Policy
--------------> Underwriting
------------------> Quote
------------------> Policy generation
------------------> Renewal
--------------> Claims
------------------> Assessment
------------------> Subrogation
--------------> Customer service

and so on...

What I see here is that at the lowest level of granularity, the business process generating or capturing the information is represented. Typically each of these items is represented by an end-to-end business process, automated or not. The details of work within the process is identifiable within these buckets (according to its own indexing scheme) and the documents must be meaningfully linked into the same work, while being available standalone. This last part is important in my opinion - the old imaging and workflow systems of years ago often held the documents within the 'work item'. If the workflow ended, the documents disappeared. Or you had to artificially tack the retention and disposition of records onto the actual business process. You could never attach more than one process to a piece of information either.

However you build out a new records structure for a business, of whatever size, the processes you run become part of it. In my opinion this can help you get to a seamless transition between what is just a written structure, and something that is actually useful for identify and finding information scattered across the business.

When it comes to technology to help simplify some of this, it makes it easier to identify if you need electronic records management, document management, report archiving, business process management, workflow or one of the many acronyms that make up a complex technology stack. Decide on the focus that helps your business work better and then ensure that fits into your information management requirements. If you try the reverse, you may not have a business worth keeping records for.

A post from the Improving It blog

To implement workflow and process automation in your business today, visit www.consected.com

The joy and pain of rolling out a new business system

As three months in Mexico City draw to a close, the business process management (BPM) based system we've been building is heading for production. Not wanting to risk jinxing it (so there is a lot of wood touching happening here), I am trying to avoid saying that it may possibly, if the stars align, be on time and to budget. Technolab and the large multinational insurance company that we have been working for should be proud, as even if we do see a last minute hiccup, the teamwork and desire to get the job done has been incredible. So, that's the joy over with. What about the pain?

The pain (at least for me) comes from the uncertainty; the last minute unexpected mishaps; the possibility that the production servers just won't run right; the fear that integration with the system of record is just not the same for production as in dev and test; the fact that I'll have to perfect meditation to try and sleep without my brain going over every last detail (again). Dreaming software is not fun or relaxing. Especially not dreaming it in a foreign language!

But its just an application, right? And its been tested?... Of course.

Its the fact that the system touches the working lives of practically every skilled worker from sales, through underwriting, to policy issuance and accounts receivables. If the system screws up (like throws every item of work into an error state) for some unforeseen and therefore untested reason, there's going to be a lot of people sat on their backsides drinking coffee and waiting. That would not be the ROI that we all hope for. But its not just this project. For me, every system I've deployed (more successes than mishaps, it has to be said) leads to this mix of adrenalin and some other unknown compound (probably caffeine).

So for now, all I can do is keep on using the revolving brain, mentally touching and prodding every last piece of the processes and applications, to satisfy myself that everything is good. Reality is, its been good for a while. We have settled, just in time, into the essential phase of stabilization and risk reduction. So I'm ready for some joy on Friday. Just a little. Seeing the first users successfully login and start working full time, full on, with their new system. If so, you could see a deliriously happy post from me at the end of the week. Please keep your fingers crossed! Mine are, and its making it difficult to type.

A post from the Improving It blog

Download the podcast of this blog post