Connectivity, Efficiency, Experiences

When looking at BPM (Business Process Management) solutions, or talking about BPM the concept, many of us think of how it relates to actual business processes or business goals, cases, targets etc. This is the main aim of BPM, to address how a business achieves a goal or carries out “work”, agreed? Ok, but my observation is, Is this right? Does the term BPM limit our thinking in real sense?

 

Outside of the business

If we take everything that we do towards a desired goal or outcome as a process, then BPM applies to everything we do in life, it’s not just limited to Businesses! For example, our own bodies go through processes every second of every day to achieve a goal. Think how we breathe, there is a distinct process, think how we turn food into energy, a distinct process, think how we run, a distinct mechanical process.

Now these examples are to simply prove a point that processes are around us and a part of our daily lives massively, which means any one process is made up of many others. Me running is a process, but in order for me to run, my body goes through a number of other processes, breathing and turning food into energy. This means businesses should not see their process as “the process”, rather as simply a smaller part of an overall and far bigger customer experience.

 

Real world example needed

To get my point across I want to use a real world example. Ok, I purchase a printer from a store. On checkout I provide that store with some basic information about myself. I then get home, install the printer and start using it. I fill in the warranty card, post that off, and then forget about it. A few days later the product breaks down, and I need to get it replaced. From the point of view of the manufacturer they don’t need to take into account any of the process I have just gone through, in order to kick off the process of dealing with the fault, but should they?

I believe yes.

 

Connectivity

Connectivity of devices and processes can have massive implications on process efficiencies, and the ability for external processes (that may not be directly related) to have a positive effect on our business processes.

First off, connecting and sharing data between different processes obviously provides added efficiencies and data accuracy. If we take our printer example, the process of checking out and paying for my printer should be integrated with the process of me completing a warranty card and informing the manufacturer.  That’s a process I shouldn’t need to be doing, and with improved connectivity of processes and data, I don’t have to. Now relate that back to the process of me returning the faulty printer, you see that process will be improved because of this connectivity in a different process. Both the store, and the manufacturer now know me, the product and the warranty, I don’t need to go through a number of steps at the start of the manufacturer’s faulty product process.

Secondly, device connectivity can have a massive impact on process efficiency, especially when connecting multiple and sometimes very different processes together. In the typical BPM world, do we take this into consideration?

Since the rise of the Smartphone, we have started to take into consideration connectivity to processes from different devices; we now see not just eMail being accessed on our mobile devices, but also ECM concepts along with the ability to actually work. However, when we flit between devices, such as our laptop, tablet, PC and mobile, often we have to do things again. Think deleting emails from your mobile device you have already deleted, think re-downloading a document we were working on etc. These are small things, but they can rack up a lot of time, and frustration amongst your work force. Now think of this from the point of view of a customer? You can see how better connected devices mean we can deliver better connected experiences to our customers, which have an impact on process efficiency.

Connectivity is a big thing, and one of the problems with multiple platforms and operating systems is the lack of connectivity. As a consumer, we like single user experiences, and we now want and like flexibility to do things whenever we want and on whatever device we want. Unfortunately having a different OS on my phone to the OS on my tablet, to the OS on my laptop and PC is not great for connectivity or user experiences. I’m not sure big players such as Google and Apple get this. Apple do it better than Google, and currently Microsoft, they learnt from the disjointed approach of Microsoft in the 90s. However, Microsoft seems to understand this connectivity and single user experience far more now, and they are moving ahead of the others. With Windows 8 and Windows Azure, one connected OS across all devices is only a few months away. That potentially provides massive connectivity bonuses to business and consumers.

 

Efficiency

BPM, APG (Adaptive Process Guidance), ACM (Adaptive Case Management) all aim to help businesses in a number of ways, raising efficiency, increasing standards, increasing accountability, ensuring compliance and improving customer experiences. These are just a few arguments for BPM thinking.

Efficiency is often looked at in terms of processes businesses own. Let’s look at our example process again. The manufacturer can improve the actual faulty printer process internally; it monitors what goes on, tweaks it here and there and improves it. However, external processes and greater connectivity should be leveraged to drastically improve this process further. Make sense?

In order to get a working printer, I the consumer, will follow through a process, which is a bigger process to that which the printer manufacturer has for handling this issue. If we step back, we can see that this process of getting a working printer spans over the store and the manufacturer, but if we step back further it also incorporates the process of me purchasing the printer in the first place. Do you see how a bigger picture of a process now surrounds my manufacturer’s simple process of dealing with my broken printer? If you do, then you can start to see areas in which we can make the manufacturers process of dealing with the broken printer far easier and more efficient than what is currently in place.

Essentially, if along the entire process of me purchasing the printer the manufacturer was thinking about the returns / repairs process, then they would want to get the warranty and customer information at the point of sale. This drastically improves the process efficiency for returns, in terms of internal efficiencies but also from the point of view of the customer, improving their relationship with that store and the brand of printer they have bought. I’m not going to break down the process further, rather I believe I have made my point, that business can improve process by taking into account external processes, especially those of their customers…

 

Experience

This post is about delivering a better customer experience. Leveraging the connectivity potential of devices and the connectivity potential of processes, business is able to improve its own processes. Taking our faulty printer example we can see how improved connectivity leads to external processes improving the manufacturer’s returns / repair process, in terms of efficiency internally and for the customer. We also see how connectivity of devices makes the customer experience far easier, simpler and more efficient, including for the manufacturer.

So with efficiency in mind, we look to greater connectivity, put the two together and you get drastically improved experiences…

Framework, solution, or both…

This week I read an interesting blog post on Case Management with it concluding that most Case Management platforms are more frameworks than workable solutions. The solution is effectively provided by the Case Manager reseller, either as their own system/solution, or as professional services with the solution being customised to your needs…To be honest, this is true of many “silos” out there, and there is nothing wrong with it. However, businesses should understand that more often than not, the solution they actually purchase is indeed a framework, the solution part comes later…

In this post though, I want to look at how you can deliver a solution and not just the framework…Or even better, deliver both as a vendor…

Why not a solution from the vendor

Well it can be very hard to put together a solution that fits and works well for all. It is easier, and in many ways makes more sense to build a robust framework, and ensure a solution that meets the client’s needs is built using that framework. There are many benefits of working this way, many of which include greater control, integration possibilities and a real sense of ownership of the solution.

Let’s also think about the complexity here for vendors. Most vendors will specialise in a particular silo, be it Case Management, BPM, CRM, ECM etc. This means their framework is built to solve that business need. Even vendors that provide multiple silos, they still focus on each silo individually. The problem arises at the business end, as that business need in the real world works hand in hand with other silos. Effectively, what is a silo vendor, cannot provide you a real workable business solution, as they only provide a part of one. This means it is down to resellers to put together “best of breed” solutions for example, and develop that solution for the business – integrating the different silos needed…

The problem I have with this approach is that integration is time consuming, can be very costly and in the long term, can cause issues with finger pointing between systems and silos. All of these are potential problems, but none the less for many projects out there, they are real issues…

We are being sold Solutions all the time

It’s true that many vendors will claim they are selling a complete solution, that you can use their system out of the box almost straight away…But in my experience, this isn’t quite true. You can use their out of the box experiences, but end users will find them clunky, and probably will hate them. Which means you end up having resellers or professional services build software on top of the framework, that meets your needs…

Also look at the solution you are being sold, how much “coding / configuration / professional services” do you need to get to a finished solution? I think it’s a few man days…

All this being said, there are complete solutions you can purchase out there, think small scale, like SAGE line 50 for example, thats a very workable solution for many SMEs. The issue here is that with bigger organisations, or more complex needs, the solution starts to show a lot of weaknesses, you can’t do with it what you quite want, you can’t integrate it, you can’t have a third party add in new windows to the UI etc etc…

Holistic solutions can help

Holistic solutions and a more holistic approach ensure your vendor is dealing more closely to your actual business need. This means that the framework delivered will be fuller, and as such, makes it easier to build a workable solution, without integration points and lots of professional services…

Vendor delivering both framework and solution

One of the big things I am working on with workFile and the workFile Vision product is framework for delivering full solutions. That may sound like classic IT vendor talk, but what I am trying to achieve is a platform that can deliver a complete out of the box solution that is a good end user experience, but also provide the flexibility needed in todays world, to allow resellers to extend the UI and core platform to meet even more needs of the customer.

So how are we doing this. Well firstly, we have a complete holistic approach now to things, there are no longer silos within workFile, rather workFile is a single platform. This means the workFile framework incorporates all of these traditional silos in one place (ECM, BPM, CRM etc). Secondly we have identified the difference between framework and solution and as such, split the user experience into its own framework, separate from the actual platform framework…

The big benefit here is a separate framework for delivering solutions built on the workFile platform. The UI framework allows us to deliver a rich and complete solution to a business. But it also allows resellers / integrators to modify and hook into not just workFile, but also its native UI. This means no additional software needs to be written on top of something, rather it is written within the UI framework, speeding up development and providing a far better end user experience.

You can even take it so far to use the workFile Vision UI framework without using the underlying workFile platform, if you wanted to. By working in this way, workFile delivers the frameworks, the solution, and the extensible capabilities to allow it to meet pretty much any business need. The end result is solutions that fit the business need more closely, solutions that can grow and evolve with the business and solutions that are easier and more empowering to end users to use…

Those BPM professionals in the Grey area. Business or IT?

I have been partaking in a discussion on LinkedIn, which asked the question, “Why majority of BPM projects fail?” Now the answer is simple. If you don’t have support for the BPM project from all levels of management, and you don’t have a champion pushing it to succeed within the business, then the projects has a real hard time to succeed. And this is because it’s all about changing the way people work, people almost always have to be forced to accept change…

Anyway, one of the issues thrown up in the discussion thread, is the confusion many have between who are IT people and who are Business people. Many comments talk about IT, but really they are talking about Business….So why the confusion, isn’t the difference obvious?

The middle man…

Ok, so you are starting an IT project, let’s say it is a BPM solution. The vendor employees turn up on site and start to look at your current business processes, the way you currently work and they try to understand your business. Now, they are working for essentially an IT company, and they are working on an IT project, with the aim of delivering an IT solution to a business need…But are they IT?

Many people see these people as in IT. Most themselves would say “yeap, I work in IT”. But the reality is they fall into the grey area. Essentially they are BA’s working on an IT project. I see them  as Business people. They don’t need to know a thing about IT, technologies, concepts, solution architecture etc etc. But they do need to understand business rules, the nature of the business and how the people work within that business. So they are business people, right?

But these same people also design new business processes, that’s ok right? But it goes further; they also model the new processes, showing exception handling, essentially building the rules into the IT solution. They also put forward their own thoughts on how things, and where they should, integrate with other systems. You see the grey area appearing? Essentially they are using administration tools within the IT solution to build the IT solution to meet the business needs. This really shouldn’t be happening. I know many designer tools are out there to allow this, and they see the BA role as a business one. But the presumption here is that the BA is all knowing, in terms of the business (which is wrong, many times they can’t and won’t discover all the processes and sub processes) but also that they are all knowing in terms of the IT, understanding IT architecture, integration issues, exception processing etc. So our BA is not really in IT, but is presumed to know everything about it. I can safely say I can count on one hand the people I have met who can do this role…

So based on this model, the IT geeks (as they seem to be called – which is a little harsh), get to work and build some integration in, build some robot apps etc, all depends on what has been modelled and how flexible your BPM platform is I guess. Oh, they are also the ones who seem to get the blame if something is missing in a process, little harsh…

That grey area

So these BA’s are not IT, they don’t need to know anything about IT to do their job. Yet they do need to understand and learn business, and how an organisation does its business. So they are in Business….But that grey area arises, because they then jump into the IT side of things to help build the solution, they essentially get the IT ball rolling, often on their own…

What’s the issue?

The issue is that a vital step gets missed out. And that is essentially where the real IT bods get to look at the business needs. Where the business needs are communicated directly to IT. Really IT should be involved before new processes are mapped out. They can foresee any technical problems, they can look at other ways of working that could be even more efficient and have a big impact on the future processes. It is this stage that gets missed, simply because the IT project relies on the BA to know everything….And that’s because, people from the organisation see these BA’s as IT. And IT sees them as the business…

The designer makes things worse

The designer is one of the big culprits here in BPM solutions. Because it is “Business focused” or business facing supposedly, BA’s build the maps and model the solutions. If that tool was not available, then they would need to communicate with IT. This then enforces that missing step…

This isn’t my only issue with the designer. I have posted a few times about how restrictive it is and how it can have a negative impact on the efficiency of the solution…

Are Stored Procedures Good or Bad? And when to use them?

There are a hell of a lot of articles / posts on “Stored Procedures are bad” or “Stored Procedures are good” all of which are written from one aspect or point of view. They never really offer much in terms of when or when not to use them for a developer (or someone at Uni or even for an application / system architect re-thinking things).  You can almost always tell the area of IT in which these people specialise in (or have their most experience) just based on their views on this subject….So what is the big problem? Why the discussion…..

Well, people like to have “golden rules” or “answers”. In this case, there isn’t a particular view that is right, nor wrong, rather only the correct view for a particular organisations requirement. Don’t leave the decision in a data architects hands, nor an application developers (both bring different skills and views to the table). So when embarking on a new project, or a database overhaul, you really need to bring together a number of key personell to ensure you use your database – and stored procedures wisely….There is no golden rule of “Stored procedures are evil” or “Stored Procedures are great”….

Understanding the real pro’s and con’s

Before you can really determine when best to use a stored procedure, you have to think about what are the benefits of using them and the negatives. Ofcourse – this is where troubles arise – some people have arguments that are valid – other ones not so valid. So lets break these down….

Pro’s

Well first off, lets think about learning this rather than going based on “what we have learnt in the past”. So, we can all agree that modularisation and de-coupling is a good thing. So de-coupling our data from our applications can only be a good thing. Great. Now how do we extract that data in the most modular fashion and having minimal reliance on anything else. The answer, a Stored Procedure. The stored procedure provides data architects (and other database roles) with the ability to maintain the database as a seperate entity (as much as can be possible). This provides great flexibility along with other benefits.

Now some will argue this could be done in a DAL (Data Access Layer), which is true, however this means that we have in effect “coupled” our database to another external layer. Now who will maintain this DAL? How accessible and easy is it to update especially if a number of LOBs are dependent on it? In addition, a DAL will be written in what language? Languages change far more frequent than our actual data – many companies will have data that is a hell of a lot older (maybe 40-50 years older) than reletively new languages. To illustrate my point, if you used a DAL written in COM+, how easy would it be for an organisation to find someone to write a web page that utilises this COM+ DAL layer in todays market place? Not great. However, can I find someone who can code that web page and have it interact with a stored procedure – oh, yes I can very easily…

Another pro – is that you can “tune” your stored procedure without really having an effect on calling applications. No code needs to be re-compiled, deployment made etc etc. All that is required is a competent data architect or administrator. This ability to “tune” is because the database doesnt have the overhead of being linked to a particular layer (or GUI if bound).

Performance is sometimes mentioned here, especially as stored procedures are compiled in some cases. Now, in recent years dynamic SQL performance has caught up – however, lets look at the bigger picture of performance. I have worked on a number of projects where a DAL layer was used, and yes, it executed the query almost at the same speed as our SP (most occasions the SP was still faster), however, for more and more complex queries and business rules, the DAL layer became slower. Why? Basically because it used data in-efficiently – bringing some data back, passing it to a business layer to implement rules before making another call to the DB. In such a case – this “technically” is the better solution – with business logic sitting outside the database, however, for performance, placing it inside the database provided far greater performance….

Finally, who actually writes the stored procedures? Often it is someone with extensive experience in this area, someone who can write the SP quite quickly and accurately. Ask yourself who will write it in a business application or DAL? More often than not the junior developer , (that could be a little harsh) or people who dont have as much experience of SQL as they could have – or experienced people who just dont have that much extensive knowledge of the data model / its architecture….In all of these cases – this can lead to poor performance queries and ultimately poor application performance….

So the supposed con’s

Many feel that you have a “vendor lock-in” which on the web – everyone hates (it seems on the web most people want the earth from their software for free and for it to be maintained by the most ethical people in the world who do it to help developers etc and not for a penny..hmmmm). In addition, how often does a company actually migrate to a different database, not often. In addition – if you write your stored procedures (sticking as closely as you can to more standard SQL) then migration may not be such a big issue. To be honest, if you migrate data – if you have a DAL or application that tie to a particular database, good luck re-coding and testing your dynamic SQL there…

Algorithm tuning is also sometimes seen as a negative, stating that millions of people (developers) tune SQL and only a handful can do that for stored procedures. This is really misguided. Developers who write SQL (even in their millions) will not bring to the table anyting more in terms of tuning than a handful of good database architects…

Security…Oh well, this is a classic issue. Many think because it runs in compiled code it is more secure. True to an extent. But how many people (developers) has access to this? In addition, database security is not as bad as it once was, with complex user/role security in place you can really lock down a database and it will only be accessed (admin rights etc) by far fewer people – with less knowing the full database schema. This last point, is probably a negative one – especially if your organisation looses a few good DB men…but its key in such cases to ensure you get proper handovers completed (be responsible as an organisation).

A big, and valid negative, is that you have far greater “power” with dynamic SQL and in a proper language. You can perform greater calculations, applie business rules etc etc. SQL is a little, well restrictive. But thats a good thing – see the next section…

Stored procedures can be highly restrictive – especially when you have a very dynamic database schema. By this I mean one which may well update itself or an application updates it due to business requirements. These are more common than you might think – though by no means are they the norm. In such cases, stored procedures and SQL are far too rigid and lacking in functionality. In such cases you really will need your own DAL…

So when to use a stored procedure and when not to…

As you may have guessed, I am more in favour of the Stored Procedure than not. However, there are those occasions when they just arent a great idea…Its identifiy when to use them, how to use them, and when not to use them for your applications that is key to wheather they are good, or bad for you…

So when / how to use them:

• Use them for basic and moderate complex typical functions (insert, delete, update etc)
• Keep your SPs as standard as possible and not over complex
• Dont be scared to have stored procedures that do contain “business logic” (do not get this confused with application logic – they are different)
• Use SPs, triggers etc to enforce data integrity (your data will last longer than your applications and their chosen language)

When not to use them:

• When your DB schema is more “dynamic” and therefore requires a more powerful language with features to understand how to use it (insert, delete, update)
• When your application requires a lot of application logic from the extracted data
• When you need to utilise a greater / more unique security model on the data (though in this case you may well use a mixture of dynamic SQL and stored procedures to get the job done)

With all of this in mind, to answer are Stored Procedures good or bad? They are great – when you use them correctly…..They are poor when your schema is too dynamic or complex and they are evil when you use them incorrectly….