Skip to Content

In the days of legacy systems, we were confronted with the problem of ‘islands of information’ which did not communicate with each other. We had in-house developed systems and packages all working independently and had to be interfaced. We had “Islands of Data” which made no sense in terms of a corporate view.

Then came ERP, with SAP leading the pack. SAP achieved the objective of seamlessly integrating data across modules. Raising an invoice automatically updates inventory, sales and also passes the relevant accounting entries. This was wonderful and saved a lot of  time and improved efficiencies and effectiveness in the corporate world.

Now let us look at the irony of this paradigm shift. The product has become so horrendously big that it has become impossible to find a single individual who knows the product in its entirety. What has this done? It has created ‘Islands of Consultants’!

For me ‘Islands of Consultants’ is more dangerous than “Islands of Data” because consultants have egos and data doesn’t. Data once interfaced will always perform the way it should. If the SD consultant does not get along with the FI consultant, because of egos, we have a problem in the implementation!

What are we doing today, we hire consultants and put them in the ‘island’ from day one. Job advertisements read ‘Wanted SD, MM, FI/CO consultants etc….” Before the person is recruited he is identified and placed in a silo. Corporates’ don’t work this way, they need consultants who see the big picture.

The emergence of the BPX community will hopefully overcome this problem. BPX consultants can play a major role in solving this issue. If I was representing the corporate sector, I would definitely prefer to deal with a consultant who can give me a solution across a business processes and not restrict himself to a module.

Is BPX the answer? What is the way forward? I would like to have the BPX communities views on the subject.

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Marilyn Pratt
    The siloed way of working that you describe here can indeed create tunnel think and islands.
    Enter BPM, a management discipline whose prime purpose is to “require organizations to shift to process-centric thinking, and to reduce their reliance on traditional territorial and functional structures” (Gartner Business Process Management Summit 2007).  At the BPM 2008 conference I just attended last week, many of the sessions described the “process maturity journey needed to execute business modularity”.  I understood by listening to the many consultants in attendance that few were actually far along this path, but I have forwarded a link to this blog to a number of folks I consider experienced for their response.  Thanks for triggering the conversation.  I am certain you will find a good deal of interest in discussing these topics with Ann Rosenberg and
    Marc Dietrich who will be attending Community Day on November 11th, together with you in Bangalore.
    (0) 
      1. prakash Uddagatti
        I agree to the coversation started by Babu.BPX should mainly concentrate on the business process mapping and reengineering tools.As mentioned in the subject the future will be “Business driven technology and not the Technology driven Business”.
        (0) 
  2. Ramesh Ramaswamy
    Dear Babu,
    Your blog reminisce my attempt to introduce this concept in one of the implementation projects.I mapped the business requirements in a traceability matrix in an excel sheet-with the business requirements in the column and the corresponding SAP requirements in the row.With this we could control even complex issues that involved enhancements,Z progm,Z Report etc.
    This helped to enable a single point of contact with the client.
    Possibly others are also using this methodology.
    From the client perspective,as this methodology afforded transparency,they too could get their feet wet.
    We found this very handy in handling changes.
    BPM is a big value add here;though we could successfully do without BPM or any other dedicated  tool.

    Regards.
    Ramesh

    (0) 
    1. Marilyn Pratt
      Hi Ramesh,
      Actually, I was thinking here of BPM as a methodology (which could be similar to your matrix approach) not at all as the technology or tool, so yes, I can see your point about doing work without a dedicated tool.
      Hope you also will be at TechEd in Bangalore where we will have many opportunities for discussion around this topic.  Ann Rosenberg and Marc Dietrich of SAP Business Transformation Consulting will be speaking about BPM methodology governance and an approach which is technology neutral.
      (0) 
  3. Bernhard Escherich
    Hello Babu,
    thanks for raising the point.
    I see a great shift underway at the moment. Solution architects are getting more and more importance in the projects as the customers are keen to get the big picture. Therfore we built up a huge solution architect community over the last years within SAP Consulting.
    On the other hand the IT departments themselves get more and more skills concerning implementations of SAP modules. This means that the demand for “silo” consultants will decrease in the future.
    A very good tool to build up the big picture in projects is the SAP Enterprise Architecture Framework which is based on TOGAF.
    As I am heavily involved in public sector projects I am very keen to get feedback from your retail projects how the big picture is built up in this industry segment.

    Best regards,

    Bernhard

    (0) 
  4. Richard Hirsch
    One of the most important characteristics of the BPX role is the ability to use soft-skills to deal with such issues. The BPX is a mediator – not only between those islands of data but also between those islands of consultants. As we have often seen, such islands often speak different languages. That is where the BPX is the most useful.

    Dick

    (0) 
  5. Nathan Genez
    two quick points…

    1.  Just about everyone on an SAP project has an ego, regardless of their employment or career path.  Customers, managers, business analysts, project managers, trainers, consultants, developers…  enterprise wide software implementations tend to draw out a lot of Type-A personalities so this isn’t limited to consultants.

    2.  Your logic is that…  SAP started off with individual skill sets, then got larger so the silos of knowledge became more entrenched.  Now that it’s getting even bigger… this will change?  I think the landscape in the market is just as likely to become even more embedded in the trenches individual modules/areas than to suddenly give rise to someone who is supposed to know enough about such an enormous area of technology that can singularly draft a successful path forward.  As they say, the devil is in the details.

    (0) 
  6. Owen Pettiford
    I agree with the problem that this blog highlights.

    I do believe that the BPX role does go some way to address this problem mainly by the fact that it highlights the need for this cross solution/technilogy role within a project.

    Some comments have pointed to the role that Enterprise and Solution Architects can plan (which I agree with) and I see the BPX role as the continuation of these roles to an operational or hands-on level.

    I have blogged about some of the conflicts that I have experienced as a BPX here The specified item was not found.

    I have also added some of these views to the “Process First” book.

    The world is not perfect and “egos” need to be managed….and the BPX is one of the people who needs to help managed the collective “ego” of the project….including their own 🙂

    (0) 
  7. Paul Centen
    Hi Babu,

    before the phase of ERP (as you described) the market dealt with a similar feature, called the “COPICS” mushrooms: a large number of smaller consultancy firms focusing to implement and adapt (custom development) IBM’s COPICS application for “production planning”. This was in late 70’s until mid 80’s. These companies were not able to scale and to manage replication of knowledge, this basically because the employees were 100% at customer side.

    With R/2 and R/3 ERP this disappeared very sudden, due to the lack in IP maintenance.

    The ego stuff, as you describe it, is basically not an intellectual issue, but a layer below of that. It’s the protection of assets in the sense to hide (meant as protection) of knowledge. In that context you might read Robert Laughlin “The Crime of Reason: And the Closing of the Scientific Mind” ISBN: 978-0465005079.

    It’s typical for knowledge owners that they like to join to reach into new information dimension regarding that topic, and “clerks”, who control, not knowing what they “protect”. This structure breaks away once the overhead to protect is much larger as the effort to extent the knowledge.

    We need still a “couple of days”.

    Kind regards Paul

    (0) 

Leave a Reply