BPM and BI enable better decisions

14 01 2010

There are many recognised and well documented benefits of BPM (Business Process Management), many of which focus around the benefits that empower users to make better decisions. The same can be said for high level staff, people who take decisions on how the business should go about doing business. Many BPM suites provide a dashboard that allows management and key staff to review process performance, throughput etc. However, do we need to know more than these basic operational facts?

Business Intelligence (BI) can help

Now I don’t have a great amount of experience in the BI field. However, I am very aware that BI (at least the concept, practices and technologies) can add real value to BPM management dashboards. While it is great to know the through put of a particular process for example, it would be far more informative to see the type of “cases” or “workitems” that are in that process. The type of customers involved, their requests, who are carrying out the majority of cases here, what other applications are having a factor on performance etc. This is where BI can add real value.

By integrating either good BI practices or a good BI solution with BPM, you enrich the overview of how a business process is performing, and to an extent, how your business itself is performing. In addition, vast time savings will be made with regards to gathering decision making variables and showing these as informative reports.

BI solution or an intelligent BPM platform?

This is the question…It’s all well and good trying to integrate a good BI solution with your BPM platform, but this won’t be simple. Because of this the market is moving to BPM vendors purchasing BI providers (maybe vice versa) in order to bring something different and more informative to their product offering.

To write a complete BI solution would be hard, however BPM vendors can go a long way to providing BI in their own dashboards, the key is time and investment. The outcome may not demonstrate as nicely “Out of the box” as established BI solutions, but many of the benefits of using a BI solution will be incorporated. I am sure we will see many BPM solutions including “open source” BI solutions in their own product offerings over the next 18 months…

There are of course exceptions to the rule. My own company provides a BPM platform that can provide BI capabilities within processes and reporting dashboards. This is done because the maps themselves and the data stored are implemented at a more technical developer level (rather than at a high level mapping environment). This provides great flexibility in what information you want to gather and effectively store ready for reporting on. The same integration capabilities are available with custom reporting and custom dashboard controls, allowing reports to integrate with other LOBs and or its own BI type of system.

Conclusion

No matter how you choose to implement richer reports, the point is that organisations should look to BI principles when executing BPM reports or viewing dashboards. The more relevant information that is available, the more likely you are (as a business) to make better more informed decisions, which can only be a good thing. In addition, financial savings are very apparent when looking at how much money it costs to generate similar types of reports from legacy systems / other LOBs…All in all, BPM and BI is a natural fit, one which vendors and customers alike should take advantage of.





ECM access on my phone?

7 01 2010

There is a lot being made of ECM and the ways in which users interact with content stored in an ECM repository. There is a real belief that more of us will choose to access ECM content via a multitude of devices, the most obvious being my mobile phone.

With smart phones, such as the iPhone, Windows 6.5 mobiles and now the Google’s Nexus, the real question I find myself asking is “will I really want to access content on my phone?” For many the answer will be “NO”, and for many others the answer will be a very loud “YES”. So what are the real benefits and issues, without getting bogged down in technical jargon…?

ECM on my phone…

Most of us like to be as flexible as possible when it comes to doing work. By this I mean, if I am on the train, instead of wasting my time (maybe sleeping?)  I can get on with some work. With your phone you can check and send some emails, respond to meeting requests etc and in many cases get quite a bit of work done before you are even in the office. The same flexibility is required when we may not be in the office for a while. Obviously my device of choice will be a laptop; however, the flexibility to be without my laptop and use my phone is something that will appeal to many of us… Because of this, being able to connect and work in a “flexible” fashion is very important to individuals and businesses as a whole.

Will my phone interact with our ECM solution?

Basically “Yes”. Most phones these days now come with a web browser (all smart phones do), and if your ECM solution can provide a browser based front end, then interacting with your ECM system isn’t technically very hard. The issue you may well face is using the device itself to navigate around the web pages and download / view the content you want. For me, this is a basic way of allowing content to be shown on a mobile phone. Most of the issues faced then are based around the device itself and what you can realistically achieve on it…

Do I have to use a browser on my phone?

Again the answer is “No”. Using a browser gives us the simplest way of interacting with content on our ECM system; it’s also probably one of the cheapest. However it isn’t the best solution for such a small device, it does make certain features “fiddly” to use, think;

a)      Searching

b)      Checking in / out a file (if you would do such a thing)

c)       Reviewing properties

d)      Reviewing an audit log / history

e)      Tracking in a Case Management / BPM system

This is because you will need to use a lot of clicks and zooming in and out using the browser etc.

The best solution is to provide mobile based applications that can interact with your ECM solution.

ECM mobile applications

If we realistically want to work and interact with our ECM platform, and for that matter, Case Management / BPM solutions, then mobile based applications is the way forward. With the power of smart phones ever increasing, having dedicated applications on your mobile phone isn’t a problem. With mobile applications comes greater flexibility as each application will be specifically designed to be accessed via devices with limited real-estate in terms of space on the screen. This makes using the applications far simpler and easier, which means we are ultimately more likely to want to access our ECM systems via our mobile device.

As we start 2010 it is obvious that ECM solutions need to provide many more ways for users to interact with them. This doesn’t mean a generic web environment / interface, rather a multitude of applications and interfaces that are dedicated to interact with your repository from a particular device.  The trick for providers is providing a single “architecture” for access, which serves all of the different applications that may interact with your ECM repository…





Case Management isn’t BPM

9 09 2009

This week I have found myself talking to a couple of clients about why their particular system cannot do quite what they thought it could. Basically, these clients had made investments in what they thought was workflow or BPM solutions. However, what they actually have is a Case Management solution. This solution is working fine for them at the moment, however, their ideas for future expansion of the system, incorporating more complex processes simply cannot happen with their chosen platform…

So what has happened? Well far too often vendors (especially those who do not specialise in ECM or BPM) claim their solution provides workflow or BPM facilities. Now I am not saying this is done on purpose to mislead customers, rather I believe it is done because they don’t know the difference between BPM and Case Management, and nor does the customer.

Most people I have spoken to about this agree with me, that Case Management isn’t BPM and shouldn’t be confused with it. This has caused some discussion out there in Twitter world. If you want to engage, why not chat to me on Twitter http://twitter.com/AndrewOneDegree) or some of these people about it @sfracisatx, @JohnBJansen, @skemsley and @DevilsRefugee

 

So what is the difference?

BPM is about control, and good BPM solutions provide you with great flexibility to go along with that control. So you have the flexibility to take control of any process within your business, no matter how complex it may be. However, Case Management doesn’t allow you to do this, rather it provides a solid one fit framework in which an item of work (Case) can be controlled and completed.

Let’s look at how Case Management can work. Typically you will have a number of “Queues” which contain work within them. Richer Case Management solutions will allow a “Case” of work to be split into smaller pieces of work, probably with each bit of work being allocated to one of those queues. Now it is up to a user agent to then open up that queue, and pull a particular piece of work (though they could be given the first one in the queue). The agent then completes the tasks and the work, and it’s then done. I know they can “hold”, “refer”, “suspend” etc but the point is, the piece of work doesn’t go anywhere, (it stays on the same logical step / activity) it isn’t moving along a logical process. Once the individual pieces of work are done, the case is in effect completed. Hence you have managed the case fully.

Now for me this is pure Case Management, it simply does what it says on the tin…

Is it BPM still though?

Now this particular way of working can be argued to be a business process, and you are correct, many BPM systems provide Case Management, and can provide it because of what else they can do. However, let’s take the same Case Management system and ask it to do some of the following tasks:

  • Automatically route the work to a particular skilled group of individuals
  • Identify and complete tasks / smaller processes that do not need human interaction
  • Automatically hold items at a particular stage and wait for other processes to complete
  • Split a task down into a smaller business processes
    • With the process needing to allocate work, move work to a different department

If it can do all these things, then you don’t have a Case Management system, rather you have a BPM system. Now the next question is, does your chosen BPM system deliver all that is expected of a BPM platform, the flexibility to use the same system across any business process?

Essentially BPM provides us with steps (activities) along the business process and provides the intelligence to be able to move work through these different multiple steps to completion. Case Management provides, if you like, a single step (activity) business process, as work isn’t being moved along to different stages, departments, etc…

 

When Case Management over BPM

Well it’s all down to requirements, and that’s how it should be. If your requirements don’t warrant a BPM platform or the ability to map out multiple business processes, then look at a Case Management solution. Case Management solutions should always be a cheaper option to BPM, because they aren’t so flexible nor complex.

 

Conclusion

Let’s ensure there is always a clear distinction between Case Management and BPM. It is confusing, but there is a logical and procedural difference between the two, and this should always be made clear by vendors to customers. Use Case Management for single step type processes and BPM for anything else that requires “movement” along a process…





Unstructured repository Vs Structured Repository

24 04 2009

I am talking here about Content Management repositories or Enterprise Content Management repositories (ECM).

This is a subject close to my heart; after all if I hadn’t started designing my own ECM repository a number of years ago with our technical director, I wouldn’t be here writing this blog…(tad cliché I know). For us, it was a passion to design the repository, and we felt that we could deliver a repository that met so many requirements at comparative low costs to customers…

I have spent sometime today wondering round some posts about repositories, structures, design principles, open source etc. Most of which I found quite interesting, however, as usual, these articles are all so very very technical. Masses of space are used to argue one particular implementation /API benefits over another, and don’t really look at real world solutions. Especially when talking about repository design or structure.

I have read quite a bit about how a repository designed with no “structure” specifications is far more flexible than one that requires structured specifications. For me, this is just not looking at the whole picture. I fear like so many IT articles, that technology and new methods of doing things are hiding the requirement for good, solid design.

 

A solid specification

Your business applications (ECM applications in this case) need to know exactly what sort of information is being requested by the user, after all, they know what they expect / want to find. Because of this, a good ECM repository MUST allow designers / administrators the flexibility to define different types or structures for content. Now I know there is an argument not to do this, rather specify query objects to locate the content, however, I find this a less elegant and messy approach. I also feel that this detracts from the number of important services the actual repository can offer, such as retention period specifications.

Even with structures being required by the ECM repository, it can still act as a generic repository and deliver equal flexibility. The flexibility to define different structures must, however, be extended to the point where each property of that structure can contain its own definition / structures. If your repository can do this, then all the flexibility in the world is at your finger tips, in a strict and managed fashion. For me this is a solid approach to designing and specifying a system that can grow with an enterprise and deliver great performance.

 

Query and Create

Whenever you query an ECM repository you should think about how the actual user will make the query, and what they will expect. You don’t want to be too strict with what they can and can’t do, but you don’t want to be so “loose” that you risk performance implications. With a structured specification approach, as laid out above, your repository provides you with the options to allow the user to structure their query as much, or as little as they choose. In this way, the user is informing the system of the resulting structures they expect. It also allows developers to build highly efficient queries for repository based applications.

When users need to create content within the management repository, this is where I see there could be an argument for not specifying types / structures for content. If you have a structured type expected, the user creating the content has to state values for the expected structure. This could be a little time consuming for users and a real issue if you have vast amounts of content that needs to be constantly added to your repository. Please note though, I don’t see this as an argument for unstructured design, rather an argument for good data capture processes and high levels of automation.

If you have a “known structure” being created in the repository, you have greater control over how the repository can work. For example, if you have known structures the following can all be known and therefore provide valued services:

·         Encryption type for content

·         Streaming rules (if required)

·         Digital Rights / Licensing of content and media

·         How and where to physically store the content in the repository

·         Specific migration and retention periods.

 

Accessibility, Applications and API

ECM repositories often require integration with other applications and services. Because of this, they really need to deliver a good API. For me, a good repository delivers a full API. The API also needs to deliver flexibility to developers to use the repository as they see fit, though without compromising security and support of repository functionality. If your API does this, then developers will be able to develop in their own style and with the freedom they require. With a good full API, developers can leverage that repository in new ways, extending the value that repository can provide to an organisation. This is key to any organisation that understands the importance of ECM.

However, your API cannot be proprietary to a particular technology or platform these days. This is where web services really help. We ourselves have spent a great deal of time ensuring our workFile Vision repository delivers a full web service API, so much so, that all our own applications only interact with the repository through that API. We know that if all our applications work in this way, there is no integration requirement that cannot be met.

Conclusion?

So what have I tried to say in all this rambling. Well, if you are thinking of investing in ECM, make sure you look at how the repository is designed, what performance can it deliver and how scalable is it. Unstructured repositories will struggle to compete with well designed repositories that allow the structured specification of various types of content. Also make sure that your future requirements are not hampered by a lack of a flexible and full API.

If on the other hand, you are a developer / designer looking to create your own content management repository, make sure you think about what you want to achieve. What expectations you have. While an “unstructured” repository store sounds attractive and highly flexible, it may well cause you issues in the longer term, especially with retention periods! Also think about interoperability. If this is more than just a design / development exercise, you are going to need to provide an API, one which can be consumed by other technologies and platforms.

 

Parting shot…

In the end, a good repository design should provide users and developers alike, with as much or as little structure and flexibility as required…