The Process Ninja

Why Building for Change is Essential

For three years now I have been wondering why the next train doesn't arrive for 7 hours. Obviously someone, somewhere on the line (pardon the pun) made a mistake. But more importantly, why didn't they fix it?

When we don't build the ability to change into our processes and systems, we plan for failure. The world is moving at an increasingly dynamic rate, so we need the ability to change rapidly to meet business needs. So, in this day and age why do we still perpetuate idiotic paradigms:

• Building systems from scratch
• Using old technologies
• Failing to replace legacy systems
• Ignoring the customer need

One day, I hope that someone will fix the system problem so that I will actually know when the next train is. Maybe then they will think to build a system that won't be so difficult to change that they can rectify things with the change of a simple business rule. Maybe they will even think about what their customers might want (bigger screens for example, so old people can read them!)

I will wait patiently, like I wait for the next train - in 7 hours and 26 minutes.

Cheers,

TPN

Taking the "IT" out of ITIL

I've worked with the ITIL framework for 12 years now and have watched with interest the changes that have occurred from version 1 to (the current) version 3.

For those of you who don't know what ITIL is, it was designed initially as framework to support IT Infrastructure with a series of best practice processes.  Over the years it has evolved to be something much more than that. 

Traditionally ITIL is still used extensively within IT departments - Incident Management, for example is the cornerstone of most Service Desks these days. For those of you still stuck in the 20th century, that's what you call the "IT Helpdesk". But version 3 of ITIL has two important elements that make it much more than a framework for IT Nerds:

1. Service Management - rather than being just a set of processes as it was in previous versions, ITIL v3 embraces a services management approach. This involves looking at business services and using ITIL's service management lifecycle to support those services. 
2. Continuous Improvement - ITIL's service management lifecycle concept embraces four key phases (Strategy, Design, Transition & Operations) which feed into a cycle of continuous improvement.  

What does this mean? Well, we now have a framework that manages the entire lifecycle of a service and which embraces continuous improvement. So why should we restrict ITIL to simply supporting IT? The answer is, we don't have to...

If we strip the IT terminology out of ITIL we can use the framework as a means of supporting ANY business service. It helps us to firstly define the strategy of the organisation, the business services to support that stratergy and provides the means to support those business services via a set of processes - all wrapped up in a cycle of continuous improvement. Incident Management? Use it in a call centre! Capacity Management - use it for a warehouse! Think outside the IT square and many applicable uses spring up.

So when you think about how to manage your strategy, your business services and the processes required to support them - remember that you can take the IT out of ITIL to provide you with a great starting point.

- TPN

ARIS 7.1 - It's a Kind of Magic...

I was lucky enough to have been given a very comprehensive demo of IDS Scheer's ARIS 7.1 recently. I was very keen to look at this version given that ARIS is once again the golden child of the BPA Software Gartner Magic Quadrant in 2010. In short I was highly impressed - and the reason for this is simple - ARIS is not just a BPA tool - it's an Enterprise Architecture tool (and more). 

What separates ARIS from some of the others in the herd is this EA approach - it's the connectedness of the tool from the top level business strategy right down to the lowest level of detail. The ability to drill down through balanced scorecards or through the org chart, through to roles, tasks and job descriptions means that their is an interconnectedness. Furthermore, job tasks and roles can be connected with portfolio management to enable complete visibility of the organisation's resourcing.

Because the tool also integrates down through to the technology via Webmethods (2 way) or Pega Systems (1 way) there is also complete visibility of the technology layer - therefore providing you with complete visibility of the CMDB!

Data being fed into ARIS can be displayed in real-time dashboards, or input data can be altered to enable process simulation to highlight potential problems with changes to processes and to enable processes to be continually tweaked and improved.

But if you want to start off with a standard framework like ITIL, you can do that too - ARIS already has ITIL and other frameworks built into the tool ready to be used (how you want to use them).

Finally there is also ARIS's "social BPM" capability: ARIS Align - essentially, facebook for BPM - a means of communicating and collaborating with your colleagues - and this can occur wherever you are in the world as ARIS align is 100% cloud based.

So, whilst I always view the Gartner quandrant with a fair degree of skepticism, it appears that there is definately some magic when it comes to the capabilities of ARIS.

- TPN

Enterprise Architecture and Process - Uncommon Bedfellows?

As a process person it is not easy to think that process is not the be-all and end-all of the world. Process is where the work within organisations is performed, but we all know that work in itself can be a misnomer. Work should be about doing the right things, not just doing things right - so work in itself needs to be guided. How do we do that?

Recently I have become more involved with Enterprise Architecture and its linkages with process. I didn't understand EA at first - I thought it was the domain of technical boffins designing technical architecture - but it's not. EA is about alignment throughout the organisation, it's about delivering business benefits.

Enterprise architecture should start with the most important person of all - the customer. The business then defines their offerring to customers in the form of their business strategy. The question then is how do we make that strategy a reality? By developing the concept of business services - i.e. services provided to enable the business strategy (each with it's own lifecycle). Business services are supported by our old friend business processes - where the work happens. Business processes are a combination of manual and automated processes, supported by technology in the form of information, application and technology services.

By taking an holistic approach we bring all of the elements of enterprise architecture and process into alignment with the customer, and from the customer down we deliver upon that alignment. So rather than thinking about processes in a vacuum, we must always consider the bigger picture. Customer and business focussed enterprise architecture can provide a framework by which business processes can really deliver.

So whilst EA and process might have seen to be uncommon bedfellows in the past, it's time they snuggle up together and make beautiful business benefits.

- TPN

P.S. My continued thanks go to Grant Moore of 601 Consulting for helping a simple process guy like myself understand Enterprsie Architecture. 

Mr Potato Head Explains SOA & BPM

I was lucky enough to attend the Sydney BP Trends Group run by Johan Nelis a few weeks ago. The meeting was all about what SOA (Service Oriented Architecture) is and how it works with BPM.

Having had no previous knowledge or involvement with SOA I was pretty keen to understand it. Not being a textbook kind of guy I am always looking for a metaphor, analogy or image to help myself to understand things and bizarrely enough when I learned about SOA and BPM my analogy was clear:

Mr Potato Head.

Why? Well SOA is all about providing flexibility. It’s all about having a modular structure of architecture that is “as flexible as the business needs it to be”. It is in contrast to the “old” IT ways of building rigid systems that are slow and costly to change. If we think about Mr Potato head as our offerring to the customer, the business decides what Mr Potato head looks like (services). Now imagine that each one of Mr Potato head’s bits (ears, eyes, hats, etc) is a business process. These processes make up the offerring or service to the customer. So the business decides what he looks like and IT plug together his individual processes out of their big box of ears, eyes, mouths, etc.

If the business decide that the want to change their offerring to the customer and hence the processes involved they simply tell IT what they want and IT go back to their big box of Mr Potato head parts and pick out a new process (ear, eye, etc!). Mr potato head now looks different as they have changed the process and the customer receives a new service or offerring from the company.

If we look at how this would have worked in the old days the business would have come to IT with their request and IT would have told them that all Mr Potato head’s parts were glued together and that to change their processes they’d have to e.g. cut off an arm, build a new one and glue it on. This would take time, money and a lot of effort.

But with our new SOA oriented business Mr Potato head can take on the world! We simply plug in our new processes to provide the business with what they need. Thus the business can respond rapidly. The Business and IT are in complete alignment.