Thursday, December 16, 2010
Tuesday, December 14, 2010
This news is interesting, since it is giving smaller institutions such as credit unions the opportunity to offer competitively priced money transfer capabilities. It starts to put in place a real competitor to the legacy fund automated clearing house (ACH) and wire transfer systems used by the banks for Electronic Funds Transfer. EFT is perceived as being highly complex and may be considered one reason why electronic payments are going to be such an expensive proposition for small businesses. If you make a payment to a small business electronically through an online banking site such as Bank of America, its likely that the bank prints and mails a check. The small business owner has the inconvenience of the paper check still. This is not an end to end electronic solution, it just suits the customer, and the bank gets to hold your money for longer.
If PayPal and S1, or similar propositions start to really compete in the marketplace, I hope this could put pressure on the big banks to start providing better and cheaper check-free approaches for business to business payments, completely integrated with real small business online banking. This is what small businesses want, direct integration, not another service that they have to transfer funds to so they can pay a third-party. The rather hefty charges, and complexity of funds transfers to the PayPal account before making the payment need to be reduced, and competition is the only way it will happen.
Monday, December 13, 2010
Thursday, December 09, 2010
A question from this blog, What's Better - Building a BPM Solution or Buying One? and an important question for companies looking to take the BPM leap. And what metrics should they use to make the decision?
Build or buy will be driven ultimately by the preferences of the organization.
1) completely tailored, business wide processes
2) solving specific business problems
If you need #1, then almost certainly you'll be buying an enterprise BPM suite, and building a lot of integration into your environment. BPM software is really a set of repeatable building blocks, made general enough to match common requirements for many business processes, not just those of one business. Therefore it seems hard to envisage building a BPM internally. Really what a business should be doing if it is looking at building software is using BPM methodologies alongside other requirements analysis approaches, and building just what is needed to make the solutions work in practice and make them maintainable in the future.
When custom processes are absolutely necessary for SMBs, an enterprise BPMS is not going to be a good fit. Even the software vendors don't use their own software, due to its complexity and cost to implement ( see my blog post about a dirty little secret )
Finally, a guarantee of success should be something you can measure. Building anything adds risk to this equation. If the solution is the right size for the problem, there should be an ROI up front, which you can balance against the risk of build-or-buy. Soft benefits alone, like customer service improvements, does not make an investment invalid, just harder to justify ( see a quick animation that explains this from the perspective of the value chain ).
Build or buy of BPM is not the question. Companies should be asking themselves where their problems are and the fastest and best ROI for fixing them.
Wednesday, December 08, 2010
Unfortunately business improvement strategies have taken the branded non-value add approach. We have branded our business improvement methodologies, Lean and Six-Sigma are two common examples, to add caché. Hell, we even retained the Japanese-named concepts that came out of the manufacturing philosophies that don't always translate well into western thinking, because it makes the approach sound cool. What, after all, is wrong with translating concepts into plain English to make them accessible to a wider audience, rather than forcing people to buy expensive training and textbooks?
Strangely enough, despite maintaining a significant amount of branding to make its concepts sound bigger than sometimes they are, Lean really does follow the concept of 'enough is enough'. Maybe not 'enough is best', but knowing when to stop to avoid wasting effort in removing wasteful activities from your business processes. So, going back to my likely to be quoted out of context quote, "good enough" really has some value. The question is, do you want to spend money making one process that is performed close to perfect when the rest of your business needs some serious fixing? It is like seeing a house with a beautiful kitchen complete with granite and stainless steel, but the stairs leading up to the bedrooms are collapsing.
Small and medium-sized businesses should be especially sensitive to this pursuit of perfection in their processes. There is typically not spare cash to be invested in business improvement. Surprisingly, sometimes the best way to get bang for the buck is to do several things at once. Make sure you reach a milestone where the work done on a project is useful, but have enough measurable objectives in place to understand which of the simultaneous projects is really going to achieve what you want. Your understanding of what is important changes as your processes improve.
Like branding, sometimes a single laser-like focus on one project ends up dragging you into a endless cycle of polishing and perfection. Mootee may be right, at least in my view: "Enough" is the new "Best". You can quote me on that.
Tuesday, December 07, 2010
Most new software system implementations require people to be trained or re-trained; they have to understand why the new way of doing things is better, how it will make them more productive, how it affects the bottom-line. [...]
Yes, BPM can work, it does work, but it’s necessary to recognise the other associated costs especially with human capital.
Friday, December 03, 2010
Tuesday, November 30, 2010
If we wanted to organize our kitchen to maximize space, we would never do things like store empty pots and pans or glasses in one place and disposable boxes of dry goods in another…we’d dump the dry goods into those empty pots, pans, and glasses and toss the disposable boxes they came in–et voila: maximized space!
It gets slightly better, as savvy computer users (not my mother-in-law) start to put things into folders for each type of work they do. Now in an office, we end up with the F: drive being the place where people throw all the junk, with a folder of "Accounts Receivable", one for "Travel and Entertainment", etc. Careful filenames keep the documents in order. But frankly that offers us little better options than knowing that an expense claim is in the bucket, and got dumped there around 3 months ago.
Why is it so hard to classify our documents by business process, and the meaningful business information that generated them? You know, keep them in context, rather than make them an issue of searching for them? Because the good-ol' PC doesn't let us do that, and we don't want to spend time naming documents and hundreds of folders in a way that lets us find them.
I have always been a great proponent of keeping documents in the context of the processes that created them. Not in the old workflow / document automation way of "it arrived in the workflow, and its stuck there", but a meaningful classification that let's us use the fact that an employee travel expense claim has meaningful attributes (or metadata) for the employee, for the accounting group, and for the auditor. Keep the information (expense form, scanned receipts, manager approval) organized in a meaningful structure, and the attributes used to identify the processes information belongs to just takes care of itself. Yes, just have an information management app that is meaningful while documents are in the process and when we are finally done with them, without having to waste time filing after the face.
Me, file documents? The documents were filed in Consected almost before they were used. Put another way, my saucepan is already in the dishwasher. My cereal is in me. And its time for another coffee...
Tuesday, November 23, 2010
|Porter Value Chain (from Wikipedia)|
Monday, November 08, 2010
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.
Wednesday, October 27, 2010
Tuesday, October 19, 2010
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.
Friday, September 10, 2010
(If it doesn't start automatically after clicking, click More then Autoplay)
Wednesday, August 11, 2010
Wednesday, July 28, 2010
- methodology - the way a company can fix its problems
- technology - applications helping people work in a more structured way
- reduce headcount
- do more work with the same resources
- improve the quality of a product or service
- 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
Wednesday, July 21, 2010
So much has been written about efficiency in manufacturing that its is time for the masses of us office-bound companies to get a look in. A production line in a manufacturing company works so well to improve efficiency of building widgets because it constrains the way the half-completed widgets move, who gets them next and what they do with them. In the back offices of companies, things aren't so easy, so it can be hard to see why there is lots of activity with minimal productivity.Take a read of the rest of the article to find out how I think that simpler online / SaaS solutions may often be better than complex and expensive enterprise software, even for the big enterprises that can afford it. This is just part of my white paper for rapid process improvement: Seven Steps to Escaping Process Chaos.
Thursday, July 08, 2010
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.
Friday, July 02, 2010
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.
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.
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.
Tuesday, June 29, 2010
- There is little agreement on whether BPM is a management methodology, a class of software, or just a bunch of marketing garbage
- The methodology people and software people can not accept that the other side has a right to exist
- BPM as a software is too complex, expensive, and lacking in appeal to CxOs to ever be as successful as ERP or CRM
- Success seems to be measured by the amount of profit the software vendors make, rather than the positive impact on a business
Wednesday, June 23, 2010
Monday, June 21, 2010
Wednesday, June 16, 2010
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
Wednesday, June 09, 2010
I'm working on business process improvement with a client in a way that some people would consider to be 'backwards'. I'm not starting by obsessively picking at a business process being performed and constantly refining it so that it works better. I'm actually looking at all the records of transactions generated by the company, which are filed and stored off-site, and I'm working my way backwards into the business processes that created them. For me at least, this is a great way to approach things.
So many times, in business process improvement, especially when selling or implementing BPM software, we already have been told which business process we are working on. A client contact has already made a business case to fix up a specific part of a business process, as she owns the particular department affected by that piece of the puzzle. As much as BPM'ers love to believe they think holistically with end-to-end business processes, the reality of the situation is that they really are just rubbing ointment on a sore spot to take the pain away in that area. Less pain for their primary stakeholder signifies success for the BPM solution, and everybody is happy - except for the fact that the organization as a whole is suffering.
My current backwards view of an organization is turning out to show a stunning landscape of interrelated business processes and information. At this point I'm not talking about 'enterprise architecture'. Oh no, nothing that technical yet. From looking at all the printed reports, paper forms, photocopied documents, Excel spreadsheet and printed then scanned emails, I'm seeing an amazing interconnectedness of activities that is hard to get at when you look at a process as just a series of tasks to be performed.
Now that I've convinced myself that the organization is like one living organism and Mother Nature has overtaken my client, how does that help me actually make things better? Well, there are two approaches to mapping out the way to take process improvement: I can ignore this new view and select a business process that appeals, starting to fix it up, digging in from the 'request' in my diagram; or I can follow the paper trail backwards, from the final result of all the work that is going on (the record), back through all the high-level activities that produced the result.
What I'm finding is that by working backwards, I'm getting a clearer picture of the best-practice straight-line business processes I'm hoping to nurture than working start-to-finish. By working from the absolute end result of the process, which is the records to be kept that are evidence of a successful transaction, I can track back through all the activities that were performed to get there. For a start this allows me to discard the waste output that is often filed because nobody really knows if they can throw it away. More importantly, working backwards tends to hide the rat-holes, exceptions and distractions that typically appear from working the other direction (the benefit of hindsight?), allowing me to see what I really need: what a successful, streamlined business process is supposed to look like within the context of the whole organization. I can then use that information to select the most valuable business processes to focus on fixing, while already having a great view of how they should work.
I like this approach to starting a business process improvement project, although I know I'm going to have to avoid confusing my client with what appears to them to be an ass-backwards view of the world.
A post from the Improving It blog
Wednesday, June 02, 2010
In technology many of us are comfortable voicing opinions about what is good, and what is not, without any practical experience. I'm as guilty as anybody. After all, you just can't touch and play with everything that exists (some of its just way beyond the prod and play level of trial and error attempted my mere mortals). But the cloud is a different matter. It is a whole mass of technology and unconventional (for software) business models that us mere mortals can touch and hopefully understand. So why was I still talking about it without truly experiencing it?
Last week, I kicked off a new program for developers who wanted a nice platform on which to build those killer business applications that they had been struggling with for so long. The Consected API was born -- or at least conceived, since its still a way from being much more than a glint in a developer's eye. So what better opportunity did I have than to put together a new environment for my little developer community than in the cloud? None really, so I bit the bullet, pulled out my credit card, and signed up for the Rackspace Cloud. Yes, the kings of server hosting, with the tag line for their level of customer service service being 'Fanatical Support' have a cloud offering. I'm pretty sure they bought the technology from somewhere, but if the hardware is supported according to Rackspace doctrine, then I'm sure I'll be in good hands.
So why Rackspace and not Amazon with its elastic compute cloud (EC2)? Because the name, the presentation of the service and some of the feedback I've been reading suggests that Amazon EC2 is way more techy than I want to be prodding and playing with while I have better things to be focusing on. Hell, it sounds like your servers can disappear at a moment's notice, reappearing elsewhere in the cloud without data or anything intact (OK, so I oversimplify), so you have to build your solution around the complexity of an underlying server that is so elastic it just rebounds to nothing, but can stretch to enormous if your processing demands. Nope, for me Rackspace offered a cloud solution I could get my head around. Its just like renting a space for a virtual machine, but the business model doesn't tie you to that space. You can shrink it to nothing, or grow it to, well frankly larger than I'm going to need.
The nicest thing for me is that I don't need to rebuild my applications to benefit from the flexibility of the cloud. I don't need specialized developer toolkits. I don't need the cloud API. There is a real operating system (of my choice) under the covers. I get full permissions to install the software I need on my virtual machine while its running, then generate an image of it online, redeploying if I screw something up, or making copies if I need new instances of that server. All from a simple web page in my private control panel. I own the spot I'm running my image on, until I choose to shrink it or grow it. Then the machine will be stored as a snapshot and moved to its new (larger or smaller) home in the cloud. No data lost. No difficult architectures. Just like clicking a button and having a virtual tech come and install more CPU, memory and hard-disk in your server. In under 10 minutes.
So, what is the Rackspace cloud? In my opinion its a different way of charging for a nice, large, well put together virtual machine environment, backed up with Rackspace's 'Fanatical Support'. I like it when some technology is as easy as you hoped it would be. In this case, it really seems to be.
A post from the Improving It blog