Courtesy of Brian Tinham of Works Management
Selecting new ERP software is only part of the task;
successful system implementations also need re-optimised business
processes and workflows.
When the time comes for changing or upgrading ERP systems,
most manufacturers that have walked the walk will agree,
retrospectively, that selecting the software itself should have
been a relatively small part of the story. More often than not, it
wasn't - and that mistake is probably the single biggest reason for
so many projects failing to deliver fully against their business
justifications.
Talk to almost any clued-up project manager and you'll hear the
same advice. Don't procrastinate over your choice of ERP: you're
never going to find a system that matches precisely what you do.
And, if you pursue that path, you'll be looking at high levels of
customisation, high implementation costs and years of delay and
regret.
Instead, spend more of the valuable time donated by your
cross-functional project team on what matters to the business.
Common consent suggests taking it from the top, meaning undertaking
the SWOT analysis and using that to define the business strategy.
Then you're into understanding what it's going to take to align the
IT to deliver on that - taking into account any new
capabilities.
And not just the IT: given that all modern systems are effectively
enablers, plan to use the 'opportunity' that changing ERP brings to
re-optimise your business processes. That's key to realising value,
whether in terms of increased business agility, better customer
service, slicker supply chains, reduced admin or all of the
above.
Of course, due diligence remains important. And, yes, that means
selecting your IT (and consulting) partner, and rediscovering and
documenting the current state business processes and IT involvement
- from top floor to shopfloor. It also means working on
business-wide data cleaning (customers, suppliers, parts
nomenclature, BoMs, routings etc), as well as considering the
migration method and the rest. But, without wishing to labour the
point, your peers will tell you all that needs to be viewed as part
(albeit an essential part) of the journey; not the reason for
it.
That's the top level thinking. Meanwhile, at the sharp end those
embarking on this journey invariably state that getting their heads
round the current and future states - and, in particular, mapping
business processes and visualising where IT fits in - is difficult.
For most manufacturers, the complexity is massive and the capacity
for any new IT to help change the way things are done is probably
unknown - and also slightly scary. There are also always those who
claim to believe that the way things run right now is pretty good,
that the law of diminishing returns pertains, and that 'value
engineering' is just another meaningless buzz phrase.
So best advice might be to grade potential software suppliers less
in terms of the software they offer - although there remain
differences and no one is saying this demands zero attention - and
more their consultancy services, and relevance to your operations
and sector. That said, also look for IT partners that can
specifically help with business process discovery and
re-optimisation, both in terms of methodologies and graphical
visualisation software.
Software assistance
ERP companies have offered the latter facilities for years, with
varying degrees of success. Who remembers, for example, Geac's
System21 Aurora business process modeller a decade ago? And it's
also the case that so-called 'pure play' BPM (business process
modelling) software companies, such as Tibco, have made, and
continue to make, a good living out of their offerings - albeit
mostly from the big corporates that can afford bigger ticket
projects.
Whatever your perceptions though, some modern BPM systems are
surprisingly helpful, enlightening and easy to use. Most now also
help to define system functionality, workflows, screens, data
handoffs etc, which in turn means serious potential for faster
deployment. Take SAP, for example. The software giant is by no
means alone, but its Netweaver BPM suite, although embryonic in
terms of uptake anywhere outside the system architecture
specialists, does look impressive.
Adrian Simpson, SAP's head of technology, makes the point that
most manufacturers' business processes don't start and end in their
ERP software. "So project teams need to be able to understand,
configure, prototype, validate and then execute business processes,
no matter where they go. That's why we introduced Netweaver BPM,
which is aimed at helping them to customise business processes [not
software] that go across applications, and to extend them into what
we call 'next practice' - in other words, not limiting them to
today's best practice."
For SAP, this is seen as an important differentiator, since it
means that project teams can not only visualise default processes,
but also configure improvements specific to them that deliver
competitive advantage, without bespoking the code or getting bogged
down in the detail. "It allows them to model what the business
processes looks like, using an architectural 'swim lane' view, with
systems on the 'x' axis, and actions, comments and functions on the
'y' axis, while the connections across and down represent the
process flows," explains Simpson.
"Considering suppliers, for example, the screen might open up
processes for bidding and taking quotations through to contracts,
then into procurement and so on to manufacturing," he continues.
"So you're mapping across all relevant systems, and with all the
orchestration revealed in the schematic right in front of
you."
And with that level of logic exposed, it's not difficult to see
that business analysts can then go on to the next level - designing
the look and feel of operational screens, with users looking over
their shoulders and making amendments in real time. "It's easy to
do the prototyping, and it's iterative. Users can say that's not
quite what they want, or suggest changing part of the flow, and the
system can be rebuilt on the fly," enthuses Simpson. "Not only
that, but at another level, once all the information and metadata
is complete, along with the integration requirements and service
calls to relevant applications, we then have something that is
executable. We hit the button and that design becomes something
that can actually run."
All well and good, but what if your system isn't one of the latest
SAP offerings? Additionally, suppose documentation is poor -
certainly at the business process level. Netweaver BPM isn't going
to help then, is it? Just so: and that observation would be just as
valid for any other mainline system and its associated business
process mapping suite.
Suffice to say that SAP's answer then is its Solution Manager,
which, in its case, integrates with Aris' independent business
process mapping software. Simpson explains that the former enables
reverse engineering of the embedded business processes as
originally implemented. Then the latter 'componentises' what's
there and helps users to make improvements, effectively re-using
the original software. "We have customers happy to run the tools
and do it themselves, while others use the services of our system
integrators," he says.
So much for the theory; what about practice? John Routledge, IT
manager at niche engineering equipment manufacturer Drallim
Industries, is one who believes fervently in the power of business
process optimisation. He says his company's own ERP upgrade, which
went live a little over six months ago, is testament to the value
of embracing change and recognising that so-called best practices
might actually be just that - and probably therefore better than
your own.
4,500 hours saving
He points to top line improvements as centring initially on
administrative efficiencies that are saving Drallim 4,500-plus
hours per year across 37 users. Admittedly, that was largely as a
result of switching new group acquisition, Horsell Electronics -
which had hitherto been underserved by IT - onto its new templated
ERP. Nevertheless, that change, he says, led to reduced lead times
in all areas of the business, including report preparation, serial
number control, goods receiving, supplier payments, general ledger
management and systems administration. Cash flow was also
significantly improved, through an electronic accounts receivable
payment interface that has seen payment terms drop from 60 days to
an average of just five.
In brief detail, the Hastings-based firm, which specialises in
equipment for the aerospace, industrial and utilities markets,
upgraded from an Avante ERP system to Epicor's latest 'next
generation' suite. Routledge concedes that, like so many others,
his firm had moved on significantly since the Avante deployment in
1999, but had not maintained its documentation. So for him, that
was the first job.
"We formed an ERP project team of senior managers from all
departments, selected for their knowledge of company processes, but
also their authority to make changes, and we started by
re-documenting everything we do. It took around three months,
getting down to action-level detail, whether on the computer system
or not. But, armed with that, we felt prepared to look for
improvements - which we kicked off by playing with Epicor to see
what it could do."
Once the team had a reasonable grasp of the system, Routledge says
the next task was modelling the compete quote-to-cash scenario. "We
tried to map that to our as-was processes and, where there were
variances, we worked on making changes to suit the new system. If
you like, business process optimisation was almost forced on us by
our insistence on 'vanilla' ERP. Sticking to the Drallim way would
have been a very arrogant approach."
Routledge observes that anyone doing this needs to take a
structured approach and tackle it in bite-size chunks. Drallim went
for a simple flowchart, with action boxes, coloured to indicate
whether or not they were inside the system. "With processes printed
out, the team could challenge one another on why certain things
were being done and what value they were bringing. It was all about
sanitising processes and, nine times out of 10, the system
preferences represented improvements."
That second phase only took four to six weeks, he says, because,
by then, the team knew what they were looking for. That's an
important point: executed methodically, business process
optimisation needn't be a nightmare. For Routledge, however,
another part of making change work was nothing more sophisticated
than user familiarity - and one way of encouraging that, he says,
was to run data cleaning and migration in parallel, and to start on
day one, rather than wait for mapping to complete.
"By using our data early, as part of the migration and cleaning
processes, people saw that the new system was delivering the right
information. They could test MRP, for example, in terms of lead
times, parts being bought from the right suppliers, at the right
price, etc - and all the time they were learning. Also, they were
motivated to look at fields, not just in terms of consistency, but
also reconsidering groups and classifications so that, for
instance, sales and production could filter and sort on the same
data."
It worked, with the approach expanding from the cross-functional
team to users, building in the usual top-down training, but also
with testing and development in parallel. And the results speak for
themselves: improvements on go-live, as above - driven by
everything from slick screen navigation to efficient analytics and
workflows.
Routledge's advice: business process optimisation is not the only
aspect you need to get right, but it sure is right up there. "Any
upgrade should be treated as an opportunity to reinvent your
business processes. Manufacturers rarely have time to rethink what
they're doing. But if you're putting in a new system anyway, why
wouldn't you work it to add value?"