Small IT team but very dependent on IT

Working as a consultant in Ireland I have had the privilege of working in lots of different innovative businesses.  Many of these businesses make great use of a wide range of information technologies – both on premises and cloud based, packaged and custom built.  More often than not management has an understanding of the importance of IT to the business (and to the future of the business) but faces challenges in how to support and exploit these opportunities.

There is a growing awareness of the opportunities offered through managed services, data centres, cloud computing.  In general these and related solutions offer the opportunity for management to focus on strategic objectives and value-add, while outsourcing some of the plumbing.  There are also real possibilities in terms of replacing or upgrading systems with minimal capital outlay.

However I see many examples of applications support and development headaches – with respect to legacy systems. (People seem to confuse ‘legacy’ with something from the dark ages – it often references software implemented in the last few years). In many cases the legacy applications have been heavily customised (by an inhouse team or the third party vendor).  As a result the company is left with a major exposure to/ dependence on a relatively small group of people e.g. one or two apps support people in-house or a small apps development team within a small third party vendor.

This seems to be a recurring pattern – a key apps support person leaves and operations are significantly impacted (time spent finding a replacement, getting the replacement up to speed, rescheduling planned development work, etc).  The size of operation does not merit retention of additional support personnel – so it is difficult to avoid the hiatus arising on departure of a key staff member.  If the apps support is supplied by a third party – then they most likely also struggle to maintain any depth in the support team.

So what is the impact of all of this?  Well, the very information systems which are meant to be adding value become a liability, a risk to the business, a delay on business initiatives, an impediment to change and innovation.

I am often asked to provide a fix – how does the company sort out this issue?

Traditionally we would have checked to see whether development has been executed in a controlled manner – user specifications, testing, training, documentation, etc.  In a smaller environment inevitably short cuts will have been taken.  Also, depending ion the development environment, they may have migrated to an iterative methodology, based on prototyping.

The longer term answer will often include a migration away from current systems, accompanied by gaining an understanding of the true cost of customisatiom.  The analyst and programming build is often only the small part of the cost of customisation – the real cost (which has to be balanced against the benefits) often arises from the dependence created on key inhouse personnel and/or third party vendor personnel.  And from  my experience most of this customisation could and should have been avoided.

So what can the company do in the interim – when they have lost the key people (either inhouse of at the third party vendor)?  Obviously look to add a replacement person(s) to the team – with appropriate skills/experience in the relevant tools, platforms and/or business environment.  But as soon as possible the company needs to start putting in place a strategy to migrate from the current serious business exposure to an operationally and, potentially, strategically advantageous situation.  Any such situation in which the day to day ops of the company are contingent on the continued availability of one or two people needs to be addressed.  And generally this will require elimination of much of the heavy customisation to migration to alternative business processes and supporting applications.

For those who have not yet hit the problem – think carefully before you customise, before you engage with vendors who do not have a roadmap and a broad platform.  Build sustainable business processes and sustainable applications.



Upgrade or replace current ERP solution

How to decide whether to upgrade or replace the ERP system

This is a question faced my many businesses;  it’s also a familiar question for me in my role as an external advisor.  And as with all of these situations there is no definitive answer.  It depends.

Read an excellent piece of AMR research written by Jim Shepherd on the same subject (September 2009).

This reminded me of a number of the core questions:

  • What are you trying to achieve?
  • Have you a plan for the business?
  • Have you an understanding of where the current application cannot meet current of future business needs?
  • Are you using the power of the current application/ application suite?
  • Are you having issues in terms of support and/or enhancements?
  • Does the application vendor have a roadmap (and the resources to deliver on the roadmap)?
  • What is the user forum telling you?
  • Have you the budget and the internal capabilities to take on a new ERP project?
  • Is the current application(and associated support costs) a fit for the size of your business e.g. in the context of any significant downsizing?

Given that ERP implementation represents open heart surgery for most businesses the decision to change is not to be taken lightly.  As against this must avoid good money after bad money.

Often there will be vested interests within an enterprise – those with a status quo agenda, those seeking other changes, perhaps off the back of an ERP implementation.   It is a key decision for any business – and needs to be made in a structured, unbiased way.

Enhanced by Zemanta

Book List: Books read recently

Books read recently

  • Richard Susskind: THE END OF LAWYERS? – Rethinking the Nature of Legal Services

    Discussed future of legal profession – challenges from clients, opportunities/threats arising through development in technology

  • Misha Glenny: The Fall of Yugoslavia

    Describes events in and around breakup of yugoslavia in 1991.

  • Richard Suskind: The Price of Loyalty

    Deals with Paul O'Neill's two years as Treasury Secretary in George W Bush's first term as President. Understandably written from one perspective. Paul O'Neill not a happy camper.

  • Alice Shroeder: The Snowball

    Warren Buffet and the Business of Life

Same risks in ECM ad ERP

AIIM’s top 5 risks in ECM projects:

Risk #5: Underestimating the effort to migrate content
Risk #4: Uneven use resulting from poor procedures and enforcement.
Risk #3: Internal Politics
Risk #2: Lack of training for internal staff
#1 Risk When Implementing ECM: Underestimating process and organizational issues
Could be ERP risk:
Data, Adoption, Politics/leadership, training/commitment, change management
and the same would apply for CRM or BI!

…delivering ERP projects…

The principles of ERP projects are no different to other projects: establish the requirements, develop a plan, resource the plan, execute the plan, implement the changes, realise the beenfits.  But the projects themselves offer several challenges for both the company and the implementation partner.

A clear understanding of roles and responsibilities is key to kicking off the project:

  • Project sponsor (Company)
  • Project manager (Company and implementer)
  • Solution architect (Implementer)
  • Implementation consultant(s)
  • Implementation developer(s)
  • Commercial manager (Compan and implementer)
  • Leads for training, testing & data migration (Company)
  • Change manager (Company) – if not the sponsor

Depending on project size and complexity certain people may fill more than one role (even several roles).  However where the role is overlooked or not respected (ie subumed into other activities) you tend to find problems arise.

The criticality of the project sponsor role should speak for itself – the sponsor articulates the vision, the 'why we are doing this', provides the motivation, drive, support, etc. as the going gets tough.

When you look at the number of roles, the numbers of people, the interdependencies of tasks it becomes fairly obvious that a project manager is required.  When the company does not take the PM role seriously the project is a likely shipwreck.  When the implementer fails in project management the project will be a shipwreck – at least for the implementer.  And good project managers are not in over supply – people who understand the complexities of a project, drive teams to meet timelines, anticipate issues and realign/ reschedule to ensure projects still achieve their objectives against timelines and budgets.

The solution architect is often overlooked.   The SA must understand the the company, its objectives and its processes.  The SA matches this against an understanding of the ERP solution and the implications of
any non standard implmentation effort.  The SA works between the project managers, the developers and, potentially, the sponsor.

The consultants understand the processes and the ERP application.  Working with the project manager they should seek to influence the company in how they use the ERP application.  They will work hand in hand with the developers in any required developement work.

The commercial element of the project may vary during its life time as requirements change or emerge, as unexpected difficulties are uncovered.  Different approaches my be taken – but it is in both parties interests that fair agreement is reached as early as possible.  Neither the company nor the client want unexpected overruns or costs.

Training, testing and data maigration are critical activities.  The project manager will identify these key activities.  However the company needs to identify as early as possible who will take the lead on these activities.  Data migration is often a source of major unexpected project delays.  Training needs to tbe thought out – for instance require sufficient early training for the testers so that they are able to use the system to perform the testing.

And, finally, who will drive the changes through in the business post ERP implementation?