Skip to Content
http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/webcontent/uuid/925b02f9-0b01-0010-bbbf-c68268bb3c41″ width=”235″/> http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/webcontent/uuid/7ec202f9-0b01-0010-589e-a51bcd596fed” width=”235″/>

Rocket Science! – Yes or No?

Introduction

The topic of change management caused some controversy in the discussion of my last BPX related blog -> click here. I had stated that change management is not rocket science, what created a detailed written dialogue about this topic. Besides the fact that change management is very important for the success of most projects, the mentioned dialogue motivated me even more to write about this interesting topic. First, let me tell you that I am sticking to my guns: Despite the importance of change management and the fact that it can make the difference in a project, it is not rocket science! And this means nothing else than: If you realize its significance and apply a good mix of tools from the change management bag of tricks plus the necessary attention to this topic, you will get it done! – Please read on to find out how. In this blog I will first look at the importance of management of change (MOC). Then I will give you a look into the change management bag of tricks I will provide a long list of tips, tools and how-tos. Finally, I will conclude with the desired outcomes.

1 – Importance of Change Management

System implementation projects cause many changes of different type and severity. How you deal which each of these changes depends heavily on the following factors:

  • subjective severity,
  • groups and number of people affected,
  • risk of ignoring, and
  • the time window the change appears until it impacts the organization.

Figure 1 elaborates this with an exemplary list from an real HR conversion project. The first column shows actual changes that occurred during this project. Next column is your subjective assessment of the severity of the change. Severity is a function of the change itself, the groups and size of group affected, as well as the risks to the project. As I said, it is a subjective assessment and it helps you to create a priority of your change management activities. After all, the risk/cost ratio of one or several changes may not be high enough to justify dealing with them. Some risks just need to be documented and accepted, what is very different from overseeing or not dealing with them at all. HR Conversion Table Figure 1: Exemplary list of changes in SAP HR conversion project Next column are risks. Please have a close look at the examples and you will know why MOC is so important. The severity of the risks shown in the table should make the importance of well planned and executed management of change (MOC) clear. The project team needs to understand that MOC is not secondary to completing the last few lines of code. A lack in MOC can make a project fail much more quickly and easily than one or a few lacking software features. So never say you are too busy wrapping up the project and rolling it out and you don’t have time to work on MOC now. The timing column also helps you with prioritizing your activities over the course of a project. Hence, it helps you to build your MOC project plan. There are two elements to the timing: When do you discover a change and when will it impact the affected groups. If this window is large, you have time to plan. If the window is small, you may have to improvise and manage the change ad hoc. In general, most of the changes will come into effect at go-live. Therefore, you want to make sure that you have the right targeted responses at or around this time. The last column, responses, really leads us to the next section in this blog. What are my tools to make sure none of the changes are affecting the outcome of my project negatively?

2 – Responses OR Change Management Bag of Tricks

Change management is fun! – Most changes are unique and for each change you need to decide how best to respond to it. And not all changes make things better. Sometimes a specific function may have been implemented in a more streamlined approach in the custom build legacy application than in the standard software package; or at least it appears that way. Here is an example: In the above HR conversion project, there was a perception that with SAP’s R/3 HR and its concept of info types, the usability of the system and the user experience would suffer. Info types are pre-defined SAP screens which house a set of related data like org assignments, address or basic pay. In the legacy application, however, the users were used to highly customized screens, combining many data element. Therefore, the user had to go to a smaller number of screens and had many data elements in sight. Hence, we had to deal with the notion that SAP was less flexible and the final SAP HR solution may be inferior in look, feel and ultimately functionality compared to the old tool. When prototyping SAP HR we actually found that having these well defined blocks of information, or info types, was a very powerful architecture. It was easy to combine them and string them into processes. It was easy to model an employee file with different validity periods for different type records (your address rarely changes but you have a new salary every year … hopefully). All these findings, summarized in some simple pictures (a cylindrical container on a flip chart with rectangles showing the info types; we then virtually picked them and strung HR processes together) we then used during an all HR kick-off meeting at corporate as well as during a kick-off with the international team. – The explanations were well received and this was never brought up as an issue any longer. We had turned a negative into a positive! As you can see in this example, communication of the change – in this example early on during the kick-off meeting – is one important tool/activity. Here is a more or less complete list of all the high level tools/activities:

  • Communication
  • Training and Involvement
  • Support
  • Strategy and Tools

Let’s look at each of these areas one at a time. Communication Communicate, communicate, communicate! – But do not get onto peoples nerves. Therefore, use several ways and channels of communication in a well balanced mix, both formal and informal. Formal channels are:

  • Frequent sponsor meetings Make sure you are in touch with your sponsors all the way through the project, for example via a bi-weekly or monthly sponsor meeting. Show them the progress in regards to the timeline and the milestones. Present achievements and challenges and do not forget to get their input also.
  • Weekly status meetings with your project team This is a given. Still, some project managers are afraid wasting people’s time and even apologize. This is the wrong approach. Use the time wisely to share important information (and changes) and have peoples share amongst themselves. In this meeting you should discover many of the issues and changes that need to be taken care of via MOC.
  • Kick-off or town hall meetings Get your stakeholders and future users involved and excited. If feasible, a life all-hands kick-off meeting is an excellent way to do this. Otherwise do a virtual kick-off via teleconference or have several smaller meetings in different locations if there is budget for this. To make this meeting worth the effort and cost, get people informed and thinking about the project and new solution. Introduce high level concepts, show prototypes and tell people when and/or how they can get involved, for example with testing.
  • Project website or monthly project newsletter A project website or a newsletter is a good way to cover basic information and questions about the project, for example for the use of interfacing partner applications. Publishing this information will enable others to comply with your timelines and changes and will keep your email inbox clean of basic requests (IDEA: Make the URL for the project homepage part of your email signature).

Do not consider the examples above as a complete list or as the master list. Be creative and find the right communication mix for your project. And do not only count on official communication channels. The in-official ones may be as important, or sometimes even more important. Here are some in-official communication channels:

  • Change Management by walking around Be visible and approachable and talk to people about the project at every opportunity you get. Of course, if you like doing this and it is not only a chore, the message will come over best. If people see you being excited about your project and the new tool, they will be more likely to join the program, go with the flow and accept or promote the change.
  • Influence the influencers OR Opinion Leaders “The opinion leader is the agent who … interprets the meaning of … content for lower-end media users. Typically the opinion leader is held in high esteem by those that accept their opinions.” (Source: http://en.wikipedia.org/wiki/Opinion_leader) Get opinion leaders on your side: Identify them, inform and involve them and get them to support and promote your project. – Your sponsor or team members from the business side are best to identify opinion leaders.
  • Open door policy Besides you visiting your stakeholders and “walking around”, invite them to join you and your team, ideally in some kind of project war room. Few people will actually show up, but many people may wander by the room or area just to see what is going on. If you are working well together as a team and that shows, through the open door, people will believe in the project, the team and the new solution.

Let’s move on and look at how training and involvement of people will help you with your change management efforts. Training and Involvement Training and involvement is really focused around the macro change of system A being replaced by system B resulting in new processes and/or new tasks. Micro changes, like the change of office location in the table above, do not require training; they only need documentation and communication (plus a brief mention or reference in the training materials). Let’s look at some different types of training:

  • Team member training Make sure that all team members have the right qualifications. Look at each individual player as well as the whole team. If a skill is lacking overall in the team, you may have to get some outside training. If a skill exists within the team but is not spread well through the team, also consider cross training, what will help to bond the team together.
  • Super user training Super user involvement and training during the project is an excellent approach to getting your software prototypes unit tested and validated early on. Get some interested people involved and try recruiting one of the opinion leaders (just make sure you tool is up to snuff at this point). At or after go-live time, the super users will be part of an official and/or in-official support structure for the new application. Again, find the right point in time when to involve super users, not too early and not too late.
  • End user training This is a major task and – other than the two first types of training – needs to be well planned and orchestrated. Assess the skill level and training needs of the organization. Have they had experience with other SAP applications and know the basic navigation or not? Secondly, look at the business need that the new users have to solve. Is it enough to just train on the new application or is there any related tools that would help them in their job. In the example of the above SAP HR implementation, like with most systems, reporting was a key need. While we had a good flexible reporting tool, we had experimented with Pivot tables in Excel and realized their power. Hence we proposed to send everybody in HR to a one day customized Excel class a little ahead of the SAP HR training. This may have been the best decision of the entire project. Lastly, you need to get sponsor buy in as well as department manager buy in that their employees will be allowed to attend a x day SAP training class (in our case 3 days) without them having to interrupt for other business related events. This caused some excitement in the management team meeting when we proposed it, but finally everybody agreed and we had virtually 100% attendance in our classes. Start the preparation of your training materials early. To facilitate this, have your content developer join as many design and prototype meetings as possible. This will improve the content quality. For delivery of the training, I think a co-teach of a technical systems person together with a business person, for example one of the super users, is ideal. This way, you will be able to put the system into the context of business policy.

Strategy and Tools

  • Strategy One specific and important strategy in a systems project is the cut-over approach. While in a small project you may be able to cut over to the new system in a weekend and almost literally turn off the old system after the weekend (in reality you definitely need to keep it around for a few weeks in case of disaster or a needed data validation), this will not be possible in a large multi national corporation with multiple legacy environments. In this situation it is key that you have strong ties to the business and you have an agreed upon migration plan in place that moves the system over time from technical live to business live in all countries and regions. This may be a project in itself. As a rule of thumb, you want to have aggressive, yet realistic plans to move all your business onto the new platform. The longer you delay the harder it will get and it is possible for some parts of the business to resist altogether.
  • Tools Tools can range from simple to sophisticated. A simple, yet effective tool is a cheat sheet for the business users handed out at go-live that shows the most important menu path or transaction codes as well as tips and tricks around printing, reporting, etc. A laminated letter size sheet printed on both sides has proven successful in my projects. Much more sophisticated tools may be needed if you change the product structure significantly and sales operations needs to be able to convert from old to new structure on the fly for instance. A small web based tool may help with such a transition. While all tools come at a cost, if justified and designed well, they should be worth their cost, especially if you count the cost of frustrated users and lost business.

Support

  • Go-live support Make sure to let people know how to get support during the first hours and days of a new systems implementation. Again, depending on the size of the company and project, consider some of the following approaches: – Have a few team members or super users present within the business department to respond flexibly and quickly to questions, possibly assigned to different business functions. – Setup and monitor a dedicated phone support hotline. Publish the phone number for this service as well as the overall support approach, including the future on-going support as part of the training. Since there will always be some issues that you could not foresee or that will not end up in your support system, stay in close touch with the sponsors and opinion leaders during the first days.
  • On-going support After a pre-defined time of a few days to a few weeks, integrate support of the new system with the regular support model and organization. Of course, this needs to be planned and negotiated with the companies support organization. Depending on the support model, knowledge transfer or training will be needed that should be part of your training plan (see above).

3 – Desired Outcomes of Change Management

Change management is an enabler to a project: it is supposed to make a good project great! And what is the difference between good and great? The difference is users that feel taken care off and know where to find help with un-avoidable learning curves with the new system. Users that are interested to learn about the new system because they were able to give input during development as a super user or during early testing. Users that know the ultimate benefits of the system, even though they are not apparent at the moment since everything seems harder right now. And sponsors that hear good things from their users about the new system. Sponsors that may even be interested enough to try it out themselves (offer them to take them through the key features again, especially the dashboards). If the news and buzz around the system are mostly positive and people are willing and excited to use it, you just completed a great project. The difference between the good or the great project is not in the extra line of code, it is truly in the results achieved by your effective and efficient change management effort. And the payback for all the extra effort will be happy customers, hopefully like the ones from the SAP HR conversion project that I used for examples throughout this blog (figure 2). image Figure 2: Happy customers from the SAP HR conversion project

Summary

I hope you now understand the importance of change management and how to go about it. The last thing I like to emphasize is that MOC is part of your project, and not a totally separate project. Therefore, I am afraid about setting up a MOC organization that is too separate and independent of the main project. I really see change management as an organic extension of the main project with all or most of the key team members, including the system configurators and developers, involved. This is the only way that the most up to date and relevant information makes it to the end-user. While this first hand information needs filtering and formatting, it is the source for success of your change management effort within your project.

To report this post you need to login first.

13 Comments

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

  1. Andre Truong
    while MOC in a context of project implementation SAP solutions is as important now as it was during R2 and R3 times, I don’t see how using good old examples can apply to the current MOC needs around innovative business process for the agile and flexible Enterprise following the Enterprise SOA principles using Netweaver Platform.

    If we keep talking about the good old “stuff”, we’ll have people keeping talking about the good old “stuff” like IMG, ASAP,…

    I thought the goal here is help organizations go pass beyond that and embrace the new “stuff” in order to unlock the potential of the SOA promises.

    Basically, MOC in the context of Netweaver as a Business Process Platform instead of R3 for example would be greatly appreciated as far as I’m concerned.

    Very few IT organizations are setup today to embrace the BPX concept, Enterprise SOA, and Netweaver as BPP. Why should they do so? and how would they do it?

    I know of very few companies that have bought the vision and are right now executing on it. Unfortunately there’re only a few and the rest of the market needs serious help to get there.

    I think that’s a great challenge/opportunity for SAP prodcut managers like yourself.

    (0) 
    1. Swen Conrad Post author
      Hi Andre,
      Excellent comment and catch; point well taken. An up to date example would make this blog more relevant or intuitive to relate to and apply. However, I think that the approach, concept and thinking of MOC does not change between R/3 and NetWeaver. The only thing that changes is the technology platform plus the increased integration and sophistication of business processes. And since change managememt is very much about the company’s end users, together with the fact that the NW technology layer is hidden from the end user, not too much should change, really. – Let’s map two of the examples in the blog to the NetWeaver world:
      Example 2 in table, ‘Change in Dev Tool’: Like with NetWeaver, the development tools and methods changed for the team of HR developers in this example. Same as with NetWeaver, but the dimension is bigger. If you deploy NetWeaver – ideally paired with a real project to immediately apply the new tools and skills – you have to train your current IT staff and bring them up to speed. This may be via external or in-house training, or via mentoring by already experienced people.
      Bullet point ‘End user training’: Excel was part of our end-user training plan in order to move HR report generation from a small dedicated team directly to the end-user. Well, today this is called Duet! Hence, if you are implementing a composite application based on Duet, please do not trust that everybody has mastered Microsoft tools to a skill level that will make them effective, efficient and happy Duet users. Test their knowledge and include a half of full day of related Microsoft software training (depending on the complexity of the Duet application of course).
      One idea to move your or your customers organization into the NetWeaver world is to promote information via webinars (organize your own one and share your NW knowledge) or by attending the SAP NetWeaver Customer Call teleconferences on Thursday mornings (I cannot find the page for sign-up right now, once I got it I will update this post).
      Again, good and valid comments! – Thanks for the feedback,
      Swen
      (0) 
      1. Swen Conrad Post author
        Here are the URLs I promised in my previous answer:

        -> SAP NetWeaver Customer Conference Call Series @ http://www8.sap.com/mk/get/us_ep_optin

        -> SAP NetWeaver Know How Network Conference Series @ http://www8.sap.com/mk/get/US_KHNC_OPTIN

        Both calls provide excellent and up-to-date NetWeaver information that will help you to drive and guide change within your organization. – The second call series may be slightly more technical.

        Sign up and judge for yourself! – Swen

        (0) 
      2. Anonymous
        In addition the MOC needs to incorporate the increased base of users who would be affected by the SOA vision.  The big question is how do we identify the constituents who need to be involved in Changed Management as the SOA vision creeps across a company. 

        It would appear the process would stay the same but the major change would be in the scope. 

        (0) 
        1. Swen Conrad Post author
          Timothy,

          I like to second this: process stays the same, number of affected users may or may not change?!

          Consider this: In order to effectively enable strategic processes, it is unlikely that we can follow a ONE SIZE FITS ALL approach. And with the ease of process composition, we may end up with highly tailored and specialized, yet flexible point process solutions. Therefore, the target group for the change may keep its size or even shrink. And in any case, if you implement a process, you need to know who your constituents are!

          Processes that will reach the biggest audience are context related, for example travel expenses. Context functions are opposite to core functions that create value, like engineering; see Geoffrey Moore’s book, Living on the Fault Line. They are still important, since administration cost are high and time spent to enter is supposed to be minimal. With disparate data sources, for example a data from the corporate credit card company for semi-automatic data entry, these processes have huge applicability for Enterprise SOA and NetWeaver. – In this example the target audience is all traveling employees, and key change management activity is to keep users informed and offer some basic training, both in a virtual classroom setup or via cheat sheet. – Imagine how a sales person will complain if suddenly he is not able to enter his travel expenses on a Sunday night since he did not know about the upcoming change and did not receive a training (sorry for picking on sales 😉

          Hope this makes sense,
          S

          (0) 
    1. Swen Conrad Post author
      Anton,

      One would hope so 😉

      But what is the most relevant testimony anyway: From IT management, from business management, or from the business users?!

      I am glad to see that you read this blog all the way to the end!

      Take care,

      Swen

      (0) 
  2. Alfred Leung
    I agree that Change Management is not rocket science.
    However, the main barrier to effective change management seems to be the cost and effort involved. Generally Change Management cost seems to be “soft” and hence is the first item being reviewed and downscaled if the project budget is under pressure to return a positive NPV. There is also a generally accepted perception, wrongly in my opinion, that “system savvy” people can learn by themselves.
    I believe the under selling of the project failure risks is probably the main culprit, with budget pressure closely second.
    However, an underlying issue often not well addressed is the “culture” of the workplace. This alone can make or break any project, IT/IS included. But it is a much bigger elephant than any other and an IT/IS project may not be able to tackle it on its own!?
    (0) 
  3. Niels-Henrik Kortsen
    Swen great article and I totally agree with integrating Change Management – or Organisatinal Change Management (OCM) as we used to call it – in any project. One can’t do without the other and scrapping the OCM budget as someone mentioned is the same as stopping the project in my opinion.

    I have often used the OCM aspects as the main driver to activate management, the stakeholders broadly spreaking, being all the people who should have some process understanding and who are the responsible for the change in people job descriptions and responsible for realising the business case justifying the projects but who will most likely not be active users of the system.

    Without OCM very few project can realise any savings. But as we are talking people every time is a different situation.

    Reading some of the other comments I think we as SAP perhaps should be thinking about how we can advise our customers on Changes in their IT departments. Moving into netweaver and SOA perhaps we also move into an area where there should/could be changes in the customers IT departments, which will not come from the result of a business process, but as a result of new possibilities.

    I often find that the IT departments and the people working there are the most conservative when it comes to changing their ways and procedures. They find it quite alright to implement changes in the business but for themselves it is an other thing.

    We train them in new tools, we offer new ways to increase their productivity but who are really talking to IT management about the IT dept’s efficiency and possible improvements as an organisation – I haven’t come across any untill now. Surely moving into SOA we also have something to offer in this area?

    Niels

    (0) 
    1. Anonymous
      Niels,

      You made some excellent comments in your reply. As I am sure that you are already aware, the problem is often much more complex than noting the fact that IT departments are too conservative, which is certainly a true statement.

      First of all, please excuse the IT generalities that are stated in this reply; however, they are made from discussions with many of my OCM colleagues and their (and my) observations and experiences over many years of working on various projects. I have tremendous respect for IT organizations and what they bring to SAP/ERP projects. What I do take issue with is the role that they are usually asked to play on these major projects.

      In my opinion, there are two aspects to the IT role in an implementation and beyond:

      1.) Too often, when companies consider moving to SAP/ERP, the management group ask their IT department to lead and organize the process of identifying the best system and then once the decision has been made, they naturally become responsible for running many of these projects. At that point, the project too often becomes an IT implementation and the “people” element is pushed to the back burner.
      I have found that when we have been asked to make an OCM/Training assessment of how a project is progressing, we often find out that the project is not properly including the business group in their process. They are not opening a constant dialogue with the business and ensuring that they are included when developing the process (i.e. creating Structured Walkthrough’s, information Sessions, confirmation workshops of new Roles etc.). The irony is, when this assessment feedback is given to the Project Management group (usually IT driven), the IT members of the PMO usually state that they believe that they have already reached out to the business; however, surveys and interviews show that this is often not the case. Many times there is truly an attempt made; however, it is misguided, or else it is not done often enough and it is not appropriately reinforced. What potentially can happen at that point, is that the IT department doesn’t want to avoid having a negative report being delivered to the Steering Committee, so they screen the feedback to either eliminate it, or have it revised to reflect their own point of view.
      In my point of view, it is very important that top management ensures that the “business arm” be included as key members of the PMO. It is essential that the Business leaders are involved at the very beginning of the project, even if they are on a steep learning curve. The business members of the PMO should definitely be directly involved in setting-up and reviewing any 3rd party assessments that are made of their project’s progress. This way they can make a non-biased judgment of the assessments and the actions that are required to ensure that their project enjoys success.

      2.) The second part of the IT equation is when we look at how the company can best position the IT department throughout the project and well into post deployment. In order to achieve this goal and best identify this pathway, I suggest that the OCM member should facilitate the project Leads through an OCM Roadmap session. In this day-long session, the OCM representative will show (setting-up with blank paper, with timelines, covering a large wall) the project milestones horizontally across the bottom of the map (from the present time, through the post deployment phase). The OCM Rep. should then list all of the major Stakeholder groups vertically on the left side of your Roadmap (including the Communication Group shown as a Stakeholder, in order to capture the required communications). The OCM Rep should then work backwards (“bottom-up”) through all of the Stakeholders, having the Leads identify what you want End Users doing at ‘Go-Live’ and then showing the activities required by all of the Stakeholder groups in order to best support the End Users.
      The OCM Rep should then have everyone look at a “top-down” view of how you will best cascade communication messages and decisions throughout the organization. This OCM Roadmap approach synchronizes all Stakeholder activities (including post deployment, in order to sustain the change) with the official timeline of the project milestones. You should have the IT department included as one of the major Stakeholder groups in your Roadmap list. The OCM Rep. should then have top PMO management, including the IT Lead on your PMO team, mapping out the transition of the IT department throughout the project and beyond.
      Clearly this OCM Roadmap approach will not determine all aspects of the future It organization; but, in addition to giving you the basis for your overall Stakeholder plan, it creates an atmosphere for terrific dialogue and creates the beginning of the “path forward” for your IT department. It also properly ensures that there is a solid communication plan depicting how the IT department should handle the difficult transition from legacy to SAP/ERP, or whatever system that your organization might be converting to.

      I hope that this is helpful and I would certainly welcome your thoughts.

      John

      (0) 
  4. Niels-Henrik Kortsen
    Swen great article and I totally agree with integrating Change Management – or Organisatinal Change Management (OCM) as we used to call it – in any project. One can’t do without the other and scrapping the OCM budget as someone mentioned is the same as stopping the project in my opinion.

    I have often used the OCM aspects as the main driver to activate management, the stakeholders broadly spreaking, being all the people who should have some process understanding and who are the responsible for the change in people job descriptions and responsible for realising the business case justifying the projects but who will most likely not be active users of the system.

    Without OCM very few project can realise any savings. But as we are talking people every time is a different situation.

    Reading some of the other comments I think we as SAP perhaps should be thinking about how we can advise our customers on Changes in their IT departments. Moving into netweaver and SOA perhaps we also move into an area where there should/could be changes in the customers IT departments, which will not come from the result of a business process, but as a result of new possibilities.

    I often find that the IT departments and the people working there are the most conservative when it comes to changing their ways and procedures. They find it quite alright to implement changes in the business but for themselves it is an other thing.

    We train them in new tools, we offer new ways to increase their productivity but who are really talking to IT management about the IT dept’s efficiency and possible improvements as an organisation – I haven’t come across any untill now. Surely moving into SOA we also have something to offer in this area?

    Niels

    (0) 
    1. Anonymous
      Swen, your guidelines and matrix are easy to understand and highlight most of the base principles that are key to managing change. Having served as the OCM Project Manager for a transition from a highly customized legacy system to R/3, I like that your approach shows that all situations are different and need to be assessed before applying the right strategy.

      The only point I would emphasize for people new to change management or to managing large system implementations is that people and business readiness breaks or makes most projects. What easily gets lost is that we are dealing with people and their individual reactions to change are never completely a science. They tend to approach the changing of how they do their job and add value from a much more emotional state than logical. So I agree that there are tried and true models for approaching change that on the surface are not rocket science, but it’s a lot like academia vs. real world. The challenge is how to effectively apply the right tool at the right time, which is an art.

      Niels’ point on focusing on managing the change in IT is right on. It seems that as companies move away from R/3 to Netweaver the impact will be huge. However, I don’t see the models and theories changing, just the emphasis. I see a need for much more collaboration on what the expected end state is for a NetWeaver organization so that companies can plan for the skill set and organizational shifts at the start of their projects. It seems that as the tools for process integration and automation become more appropriate for functional users they require less technical assistance which might indicate that IT role will move to behind the scenes.  Are there any good studies or information available on what the organizational impacts are for companies as they move away from R/3? Thanks.

      Thad

      (0) 

Leave a Reply