Showing posts with label workflow. Show all posts
Showing posts with label workflow. Show all posts

Wednesday, January 30, 2013

Big Data, gold nuggets and the email abyss

Gold on Wikipedia
Big Data is a big buzz in the software world. It is an attempt to create small nuggets of gold from a steaming mass of information. It is not a product or a theory, more a collection of tools and platforms for organizing, analyzing and visualizing masses of data in new ways. This isn't a post on which vendor has the best visualization, the best data management, or whatever. It just provides a quick glimpse into what Big Data is, and how one of its biggest failings is common to small businesses as much as the huge research establishments that coined the term.

Big Data has sprung out of the desire for corporations to gain more meaning from all the data they collect every minute of every day. The information they are collecting about customers, about activities people perform, what they buy and the decisions they make. It is based on techniques grown in scientific research such as the Large Hadron Collider (that enormous “atom smasher”), that attempts to make the results of its 150 million sensors producing millions of sets of data every second into something that mere humans geniuses can understand. It provides medical research with a ways to make the human genome project into something more than a big experiment, developing drugs to address real diseases. And of course, government, with ways to meaningfully understand the requirements, trends (and tax evasion) of tens of millions of citizens.

Big Data is one big funnel, with megatons of data flowing in the top, and ounces of precious observation dripping out the bottom. And just like any organization, dealing with any insight, issue or lead it is at this point the Big Data analysis organization falls over and resorts to... email. All that effort in understanding an aspect of client behavior, drug interactions, or financial transactions takes real human effort. The care taken with a valuable result it is to dump it into a large abyss of junk mail and Facebook notifications.

Large corporations, governments and small businesses are all alike; everybody suffers from the same issue. They spend a lot of time working on problems, finding leads, understanding clients, but have no way of really organizing the useful information into something meaningful, to ensure that the value in the data doesn't get lost. That the potential new customer doesn't just forget she asked for information on your website. That your biggest client doesn't get upset at poor customer service and Tweet #fail about it to the world. That the analysis of your customer’s spending patterns doesn’t just leak out the bottom of a busy executive’s iPhone messages.

Sometimes email is good enough, but often we all need just a little more organization of information, a defined business process to follow and some simple management of who gets to see what, when. This combination of workflow and simple tools is all that is needed to prevent your own Big Data gold nuggets disappearing into the email abyss.

Follow more of my information management, Big Data and process rants: @consected on Twitter. Or ask me about how to prevent the precious information in your business leaking away.

A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com

Wednesday, July 20, 2011

Reporting - or processes 'gone bad'?

My clients have a range of experience in improving the way their business processes run. They range from "expert" to "what's a business process?". After a little while working together, they generally come to the agreement that the Phil Ayres view of the world is that "everything is a process". Not in a bad, bureaucratic way. Instead, if there are a series of steps to be followed to achieve a task, and you have to do the same work more than once, why not make it easier for people by providing them guidance for what to do next, and maybe even automate a little to remove the drudgery of some really repetitive activities? Not surprisingly, I would treat many of the reporting functions that businesses perform as potential processes, gone bad.

Businesses create reports of everyday activities for many reasons. They believe that it is to provide supervisory control over the work that people are doing, to make sure that nothing is missed. In reality, mostly reports are created and used just because that is the way the back-office computer system manages can tell them what is going on. Why reports? Because it is easy for a system to put together a snapshot of data of the status of work, and dump it onto paper. Many systems have very little understanding of a business process, beyond the series of options they present on screen during data entry. A report is the best they can do.

Reports can be really troublesome for businesses. They represent a queue of work from yesterday, or last week. The information on them is already out of date, and there has already been a lag in handling any of the items on the report. Sometimes, batching up work like this can lead to more efficiency (i.e. less overall manpower required to finish the work), because one person plods through each item in turn without having to thing too hard. Sometimes, it just means that people get upset waiting for a response to a simple question. Really, if a report represents a list of work that is currently outstanding, and tomorrow it will show the same work with a different status, how does it really help us, beyond showing us that we have work?

Of course, sometimes you just can't get away from reports. They make sense. They show what is going on in the only way the back-office systems know how. In many cases, managing people from the information on a report is going to lead to trouble. In other cases, I have been asked to put processes around the distribution of reports, to make sure people actually read them to know what work they are supposed to be doing. In some cases, this is acceptable - its just a checkbox that says, "I did my review". In other cases you end up reporting on reports of reports.

Consider the reports you have in an organization. Look at the ones that are handed out to people to check off their work as they do it during the day. Behind each line on that report is often a business process. The person doing the work knows that process. But if that person takes a long trip to Hawaii, do you know what that process is, beyond highlights on a printout? Wouldn't it be better to notify people of the work sooner, and guide them to completing it faster? That is what business process improvement gives us. Escape from "processes gone bad".

A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com

Friday, April 01, 2011

Justifying business process improvement without being a fool

Drawing HP 9830 desktop computerImage via Wikipedia
This year is the fifteenth that I have been working with business process management, document management and business information systems. Or when people ask what I do, "I'm in IT, but I can't fix your PC". Over the years not much has changed. The same business problems are still there. Companies still have an over-reliance on paper or email, because it is just too hard to get started in a process improvement project. Communications with customers are still on paper. Yep, you can get your bank statement online, but that isn't a transaction that results in a business process. Nope, processes are still manually guided by individuals driving a desk and an email account. Am I a fool to think that people want to change this?

In the last two years, I have been focusing more on small and mid-sized businesses. They seem to offer a great opportunity, hanging on through grim economic times, and needing some attention to be able to work better. The problem is that there is never a lot of money or time to spare in small businesses to change the way things are done. Rightfully, people focus on doing what needs to be done right now, trying to grow the business (or just stay afloat). The idea of adding some process rigor, to make it easier to do common repetitive tasks in the future, just doesn't figure. In many cases, a process incorporates a grand total of one employee and a customer. A checklist is a more effective process management tool than a formal workflow, and managing information, data and documents with minimal hassle is a much bigger issue.

Mid-sized businesses have process needs that are reminiscent of the processes I have worked with in giant corporations. Since the multinational monsters are always split into business units and smaller departments, the scale of what needs to be done is often the same as the requirements of a mid-sized company anywhere in the world. Which is great news, as that means I have some great experience to offer these smaller companies from my time spent with the big guys. 

The problem is this: it is far more transparent where the cash comes from to pay for business improvement in a mid-sized company than a multinational corporation -- the owner's bank account. In large corporations, you can make an ROI and justify it two levels above you, and you're still not even in the peripheral vision of the CEO. In a mid-sized company, the ROI has to be real, and offer real results.

So am I just fooling myself trying to work with mid-sized businesses? Or will the lessons of transparent decision-making make me into a better process improvement specialist? My job is no longer in fabricating an ROI for an enterprise software salesman to present to his prospect in the department of a huge company. My job is to recognize that mid-sized businesses have process problems that need fixing, in sensible, justifiable ways. And if you can't justify making a change, things will carry on fine just the way they are. 

Reality is, in 15 years my job hasn't changed. I'm still "in IT, but can't fix your PC". I just have to focus on the real business problems, not the ones that used to make a salesman a fat commission!

A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com
Enhanced by Zemanta

Tuesday, February 15, 2011

Why are we afraid of accounting processes?

office of Jacob Fugger; with his main-accounta...Image via Wikipedia
I didn't question it too deeply when I was a product manager for an enterprise Business Process Management (BPM) software firm, although it was always there nagging at me: why don't we do more work with accounting systems and the Finance team in general? They are core to the running of a business, but BPM (at least the stuff I worked with) generally tries to avoid those types of business problems. Looking back on it I think there are two easy reasons. But before I get to them, I'll repeat to myself and others the justification that always came out from the marketing team's collective mouths:
Our solution, ExeClassyProcess720 (made up name, and now waaay uncool as any teen snowboarder will tell you - since everyone is landing 1080's now) focuses on the bigger business problems. You know, like the ones that address the customer facing transactions which when done consistently well help companies attract new clients and make current clients more profitable and happier. That back-office stuff doesn't interest us because that involves working with accountants, and they never have any money to spend.
That's a fictional description of how enterprise BPM justifies any particular niche it works within. The real issue is not the first piece of the discussion, which may be a very realistic way of positioning an individual product if that's where its strengths are. But it is the second piece that really gets to the meat of the matter: it is perceived that any team that reports to the CFO is unlikely to have any money to spend on improving how they work. Is it really true? After all, Oracle seems to do a pretty good job making money out of businesses requiring Financials packages and all the related modules.

So BPM software vendors go the easy way - they look for the obvious issues that they can solve, then when they run out of the easy stuff they get stuck. So during a vendor's decline, it goes down justifying to itself why it can't address the thousands of other process problems that appear in a business, because the mind-set is still locked in the "can't go near the Finance team" mode.

Back to my two easy reasons why BPM avoids anything that has accounting software related to it:
  1. BPM'ers are scared of accountants as we don't know their business
  2. BPM doesn't play well with other software, despite all the hype

Why are BPM'ers afraid of accountants? We've been pretending we know or can learn other people's business better than them for years, so why can't we raise the same level of BS with accounting? Probably because the numbers don't lie, whereas there is such a lack of formal measurement in other parts of the business that its easy to "bluff it and hope" when fixing some of those other business problems. 

The reality is that accounting packages really don't address well many of the inputs and outputs related to the financial running of the business and could really do with some help. I'm thinking of travel expense reports, accounts payable invoice handling, and even the financial planning and forecasting process. These are ripe opportunities that any BPM'er could address, if they could get over their allergy associated with accounting.

The fundamental issue I think is that enterprise BPM is put off by the fact that an accounting system exists and is the guardian of its data. Business processes can only touch that data, feeding it, watching it for an hour or two like a good aunt or uncle, but always returning it safely and soundly to the watchful accounting system when its time is up. Despite all the 'web services' hype, BPM tends to be greedy. It wants to consume that data, chomping on those healthy numbers and mixing it with its diet of junk food data from operational processes. If it really can regurgitate those numbers in any useful form, they needs some really good cleaning up before returning them home.

Despite the rather gruesome imagery, BPM just doesn't play well with others. The accountants that BPM'ers are afraid of will make them look dumb, and the data that those accountants so carefully enter into the accounting system are just too pristine to mess with in a BPM solution. So BPM software and practitioners back off, and wonder why the big consulting firms just get bigger. 

For small firms like Consected this is great. It leaves plenty of room for financial management systems, ERP, and big consulting firms to do such a bad job that eventually the CFO will recommend some new investment in technology, with a proven ROI (imagine that in other parts of the business). At that point the non-BPM crowd get their chance to show that business processes can be made better where there is an accounting system and that we can all play well together.

A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com
Enhanced by Zemanta

Monday, November 08, 2010

Advertise all you want, but what happens to the leads?

Advertising a small business's products is great, but the leads you get from your advertising investment are what matter. I spent a morning at the Javits Center in New York City last week, thankful to be out of the rain for a little while. One side of the building was taken over by the super-fit marathon runners preparing for a grueling 26 mile Sunday with some retail therapy buying fitness clothing. The other side was largely taken over by ad:tech, a chance for media channels, technology and ad buyers to uncomfortably mingle in one place. It is interesting that LinkedIn ads occupied a booth maybe 8 times the size of Microsoft advertising.

For me, where the rubber meets the road for advertising is when all that spending pays back and you get solid leads. The ad:tech presenters I heard were so overcome with excitement that you could count and measure these leads, slicing and dicing them in every way, that nobody seemed interested that you might actually want to follow up on those leads. You know, see if the leads are real, what the potential customer's need are, start building a rapport with the buyer. Nope, the most exciting thing apparently is drawing a pretty chart so you can optimize your advertising messages the next time.

So, you all shout, "just put the leads into Salesforce". Yeah, well how many small businesses have got through the learning curve of Salesforce to actually make it a useful system? In a quick poll I made, only one had finally invested the resources needed to get it to work. Even then, the leads coming in end up being entered laboriously by hand from the website. But hey, they can now get fancy reports to see how many leads are in the funnel. And it only costs $25 per user unless your are considered 'professional', in which case start considering how it will impact the kids' college funds.

Along the same lines, I have to relay the little chuckle I had when I walked past an expensive ad:tech expo stand (I won't name the company). The rep was talking to some interested people about the service he was touting. They asked for a copy of a case study, which he didn't have to hand. So what did he do? Scribble the person's email address on the back of one of his own business cards and promise to follow up. "But if you don't hear from me, do drop me an email to remind me", I heard him say. Yeah, lost cause I thought to myself - I wonder how many leads like that were wasted?

So, Salesforce takes some effort to get start on. If you already have it and are advertising to get some real leads, bite the bullet and work out if it really will work for you. I use my own software to capture lead information received face to face and on the web, through a simple contact web page powered by Consected. It gets the information directly into a lead workflow, helping us follow-up and track the responses. Fancy analytics, not so much, but to be honest I wouldn't know what to do with them even if they were there. It takes a company investing way more in marketing than we do to be able to really make use of that information.

If your company would like to improve how it captures and tracks its all important customer leads, contact us and I can help you get up and running in about an hour.


A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com

Wednesday, October 27, 2010

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

Tuesday, October 19, 2010

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

Wednesday, May 26, 2010

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


Monday, May 24, 2010

Despite Twitter, email is still where we communicate

I have a love-hate relationship with email. For tracking work and tasks to be performed, especially in common workflows, email sucks. For communicating with people, the 'offline' nature of email is perfect, since you can send a message and that message will sit and wait in the recipient's inbox until they get a chance to read it. At the other end of the spectrum, Twitter and Facebook feeds just can't claim that: the messages are so transient that they are more like watching TV or listening to the radio, so if you weren't staring at the screen when a post came through, it is likely you'll never know about it.

So my renewed love of email (over social networks, at least) was given a little spark by the news that Constant Contact (don't claim you have never received a newsletter or event invitation from a company using them, because I won't believe you!) acquired Nutshell mail. Why is this interesting to me, or you? Well, quite honestly Twitter and Facebook really start to stress me out when work/life balance skews itself in the 'work' direction. I want to follow what is going on in the network of my friends, associates and the companies I follow, but keeping my head in an application like TweetDeck is unreasonable and a terrible distraction. So the idea of getting a notification email summarizing everything that has happened in my social network world, that sits there until I'm ready to decompress a little and read it, seems like a great idea. Finally, there is a better chance that I will not miss the last minute wedding announcement from a certain friend the far side of the world (you know who you are...), and that I will not miss another VIP announcement related to a local event that my small business is sponsoring. This is what Nutshell mail can offer, a nice summary of what is going on in your online social world, in a consumable email, ready to read when you are ready to read it.

So I still think that email sucks for work that people do in offices that is routine and repeatable: HR recruitTell him its about self-promoing; employee onboarding; travel expense claims; account payable and invoice tracking; new customer account opening; and so on. If you do these types of work regularly, you don't want the tasks getting lost in your email inbox, the same way as you don't want to have to stare at your Twitter and Facebook feeds all day long to know what is happening that affects your business or makes your sales efforts generate more leads. Email is great for less distracting communication, since it isn't just the Twitter equivalent of a crowd of people standing in a room shouting and waving 'HEY, LOOK AT ME!'.

I'll be interested to see where Constant Contact takes Nutshell Mail. It seems like a great addition, as it puts important messages for you where they should be: in your inbox. This ties in really nicely with the process improvement work I do with companies, where we work to free up employee's email inboxes by taking the routine work out of them, leaving the inbox to do what it does best: hold messages you need to know about but can deal with later.

A post from the Improving It blog

Edit ... OK. So the scoop is I'm married to a senior-ish person at CTCT. I'm not being paid for this blog post (the obvious pay-back is no more than you'd expect - and a whole pile of chores to complete at the weekend). And if you have read my blog before you'll know that this post is as relevant to the constant information sharing (and subsequent self-promotion) that is a blog such as mine. There you go - official cya declaration done. Oh, and the second declaration is that as much as I enjoy the concept of Facebook and Twitter, they really do stress me out. But please do follow me anyway at http://twitter.com/consected

Cheers, Phil

Monday, February 22, 2010

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


Thursday, February 04, 2010

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