This blog post first appeared on OVUM Live
Ahead of Ovum’s sixth Annual Business Process Management Forum, we gathered the thoughts of James G Smith, Head of Process & Systems Improvement, Birkbeck University of London and Tomasz Jasinkiewicz, Account Director, Bizagi.
In an insightful overview, James talks about his view of Digital Process Automation (DPA) in the context of the Higher Education sector, and Tomasz gives some excellent best practice advice for enterprises that are embarking on DPA projects.
James and Bizagi will be delivering a joint case study at the event, entitled Achieve Operational Excellence through DPA: Accelerate administration processes and improve student services.
Ovum: DPA Mantras – please share with us with your favourite DPA or work adage?
James Smith: There’s no such thing as an IT project!
Ovum: What is your job function with regard to DPA, and what are you most looking forward to at the event?
James Smith: My role at Birkbeck entails both the day to day management of our Corporate Information Systems, and the developmental improvements to those systems, and crucially the business processes that rely on them.
At BPM Forum, I am most looking forward to hearing from professionals in other industries who are facing the same primary challenge – translating business requirements from process owning departments into executable processes – because the difficulties are usually the same, but the creative solutions are often not – which is exciting as it means we can learn from each other.
Ovum: What do you see as some of the key challenges facing higher education, and how can DPA assist in meeting these?
James Smith: The challenges are almost certainly not unique to HE! Do more, better, as efficiently as possible. This is particularly true for our support services – our students are now consumers paying significant fee for their education.
We aim to make their experience with us as slick as possible, minimising the impact of non-value-add processes – both in terms of how our students experience them, and the proportion of what our students pay us that we spend on them. Streamlining our processes is critical to this effort.
Ovum: Business and IT often have completely different understanding and expectations about DPA, where do you feel this difference lies, and how do you align these?
Tomasz Jasinkiewicz: There’s often a miscommunication and distrust between the two communities that impedes alignment of strategy and execution which in turn undermines the true value of DPA.
Business stakeholders come with a lot of potentially conflicting requests from DPA– strictly enforcing procedures to increase productivity; quickly and flexibly adapting those procedures which don’t deliver; measuring and analysing the KPIs with all the data in the world – but all immediately and on a single plate. A lot of “what-ifs”, “maybes” and moving targets. On the other hand, IT quite often sees BPM as yet another integration layer. And they want everything written in stone.
The business frequently underestimates the value of process and data modeling – they believe that modeling creates just unnecessary admin that the IT guys will hide away. They may prefer to create a lot of “manual strategic reports” because “I can do it faster than those slow IT projects”.
On the other side of the chasm, the IT puts DPA into the old bag labelled “Integration” – all your middleware, enterprise buses and transmission protocols are already there – secure in the hands of the top technical talent.
Resolving this type of conflict requires a different way of thinking – blurring of the traditional role boundaries. Business process owners need to become more tech-savvy, while solution designers need to become business architects. Process and data modeling is where you bring together open minds – but even they often become stuck. Business wants to see processes simply, whereas IT are understandably concerned with the underlying details.
Take adidas – they kicked off its DPA initiative not as a top-down corporate program but through a series of bottom-up departmental projects, still tied to corporate-mandated improvements. The first projects were picked from the areas where the “blurred mind-set” was available – business owners were tech-savvy and willing to participate in the designs, while the IT leads were professionals with strong background in integration technologies but very business oriented way of thinking.
It was still critical to keep both parties engaged. What kept them moving fast forward was a good modeling tool – one that allowed the business to actively participate in process discussions early on, and to recognize “their” data even when turned into a tech language – and one that turned all those models into running processes which were still fully understandable for the non-IT team members.
In short: in order to break the traditional Business-vs-IT barriers you need to bring together the people who are willing to learn the others’ language and arm them with tools to ensure nothing gets lost in translation.
Ovum: Where should organisations begin as they embark on the search for a BPM solution to meets their needs?
Tomasz Jasinkiewicz: You want to be 100% confident that the solution can deliver on its promises. Fulfilling promises involves three elements: the technology, the people and… the promises.
Start with the promises – those that you give to yourself. There’ll be a lot of candidates for your pilot project so assess them and pick the one that will let you deliver clearly visible results with a relatively low effort. Promise yourself something that’s worth the effort but don’t go too heroic with the pilot.
Then look at the people – your people. DPA is a whole new discipline for many of them and you shouldn’t have to walk it alone. Check out what guidance, training and existing user community is available. Access to complete product documentation, to free online training courses and to knowledge sharing forums will significantly shorten your learning curve.
Then look at the technology. You need to be able to try, test and explore the software for yourself – without restrictions on functionality, system size or trial time. Pick a technology which you can fully scrutinise before you sign a devilish pact with your friendly salesman (I’m a salesman by the way, no offence intended).
Finally, go back to the promises – those that the solution vendor gives to you. Insist on seeing a Proof of Concept (PoC). All vendors are able to present a very slick product demo, whereas a PoC allows you to get under the bonnet – to see not only what you get but how you get it.
Take one of your existing scenarios and invite the vendor to your offices to work on the process together. This isn’t a full pilot, so don’t go too heavy on integration and process complexity yet. But the idea is to explore the platform and make an informed decision about whether you can work with both the software – and the vendor – in the months and years ahead.
If the solution and the vendor meet all these criteria to your satisfaction, then you’re well on the way to finding your ideal DPA partner.
