tag:blogger.com,1999:blog-1298579225598303192024-02-28T20:53:36.175-08:00SAP: loathe it or ignore it, you can't like itUnknownnoreply@blogger.comBlogger89125tag:blogger.com,1999:blog-129857922559830319.post-45381361930935877792012-09-09T13:31:00.001-07:002012-09-09T13:31:52.186-07:00I'm still hereAs you may imagine, I've been pretty busy over the past few months. There's been a lot to do and not much time to do it all in. I seem to be living out of a suitcase for a substantial amount of the time and the weeks have flown by as I try to get a grip on the things I need to learn and start getting plans for the future in place.<br />
<br />
A number of people have suggested that I ought to continue the blog, to highlight the key things that I've learned and offer suggestions for those undertaking a new project. I like the idea of this; as I've said, I would really like this blog to have a more positive purpose and the concept of summaries would fit well with that.<br />
<br />
I've started to put together a basic outline; it's still a work in progress, but I hope to be able to post some items on a regular basis. I'm going to say that I imagine that some people might not agree with some of the points I make; I think that's fine and I hope that you will feel free to add your comments where you think that I may not be on the right track.<br />
<br />
Keep an eye open; I hope to get a few new postings out in the next few weeks, subject to my work permitting!Unknownnoreply@blogger.com129tag:blogger.com,1999:blog-129857922559830319.post-56562615404566991212012-06-17T14:24:00.001-07:002012-06-17T14:24:35.818-07:00That's all, she wrote...I did say that I would keep you all updated - so here is what's been happening.<br />
<br />
Before my last post, I'd had a number of interviews and was waiting for some response. About a week after the post, I got a call from one of those companies, asking me to attend a second interview. This was to take the form of a presentation to their entire board of directors - so not too much pressure!<br />
<br />
On the actual day of the presentation, I found out that in fact there were only two candidates - myself in the morning, and another guy in the afternoon. I'd put together a short presentation using PowerPoint, illustrating some of the key achievements and how I had managed the various projects at my current role. It could have been a poor start as their presentation equipment wasn't functioning - but I quickly worked out what was wrong and after that, it went very smoothly.<br />
<br />
The actual presentation was about 20 minutes and was followed by a Q & A session that I'd been told would probably be just over an hour - in fact it went well over 2 hours. A lot of it was about the specific areas that each director had concerns over, but the biggest single session was about SAP. They have plans to implement this, and have had several meetings with an SI who gave them the SAP line, but it seems that they've all heard of the various failed projects, and wanted to hear from someone that had actually worked on a project to get an independent view.<br />
<br />
I really got a buzz out of the meeting - I seemed to get on well with the people concerned and I got the feeling that we connected really well. Certainly, I felt strongly that I could easily have worked with them and would have been more than happy to do so. When I left, I was a bit drained, but really happy that I had put myself across well, and felt that I'd done a great job.<br />
<br />
Anyway, a couple of days later I got a call - and the response was that they were going to offer the job to the other guy. However, it was made clear that they had found it a really tough choice - it appears that both of us had done well, and in the end, the other guy got it because he had been on two SAP projects to my one.<br />
<br />
What was interesting was a comment made by the CEO. He highlighed that we had both been asked similar questions about SAP, and our answers were almost identical. We'd both highlighted the kinds of problems that could be faced and how they should go about addressing these. Specifically about controlling the SI and managing expectation of users, as well as things such as testing of data and following correct procedures.<br />
<br />
So, I felt pretty good about the result altho' I didn't quite get the job. But then 2 hours after the call, the phone rang again. This time, it was from another company that I had spoken to almost 2 months before - and they wanted to offer me a job. The role is pretty much what I am currently doing in terms of managing an IT department in a manufacturing environment. It's a big company so there is a lot to do, but I'm confident that I can do a good job for them<br />
<br />
What was interesting is that they have actually considered using SAP in the past, but did nothing about it - they still have an old ERP system that seems to have been around since Adam was a lad. I don't know if they will re-consider, but I get the feeling that part of the reason they want to get me on board is that they will have to look again at updating their systems, and want to get someone with experience of an SAP implementation within their staff.<br />
<br />
There was a slight hold up on getting the details confirmed and some queries about travel - it appears that they want me to work away from what will be my home site for a while. It appears that they have some specific issues and want these to be addressed - I don't think that it will be possible to get it done in the time allowed, but I think that getting a good understanding is important. Once that was all sorted, I told my current employer that I would be leaving.<br />
<br />
Their response was not that positive - well I'm not that surprised. But instead of asking me to leave immediately which I fully expected, they wanted me to stay on for a couple of weeks. Altho' I've tried to ensure that I spread the knowledge around, there are a couple of areas where I have done more of the work, and they wanted to make sure that there would a smooth hand over.<br />
<br />
Anyway, that is now in the past. I start my new role tomorrow and I must confess to be a tad nervous as well as quite excited. I have a weeks orientation in the manufacturing section of their second biggest site, plus they want me to visit a couple of overseas sites as well. I think I made need to get a second suitcase - drop one off, and pick the second up one before heading off again!<br />
<br />
The family are also quite excited - and a bit pleased that we won't have to move straight away. It's possible that we may not move at all - I have the option to work from a place not too far away, and still look after all of the sites. Technology, it's what we do - and remote working means that we can be as effective from any given site as any other (or even from home).<br />
<br />
So, for the moment that will probably be it. I had thought about adding a couple of extra posts to this blog, just to summarise some of the things that I had learned, but I'm not too sure yet if I will have the time. As you'll be aware, I've kept this blog anonymous as I wanted to make sure that I didn't put myself in the way of losing my job. Altho' I'm moving on. I'm going to keep it that way as I may be working on an SAP project in the future, and don't want to leave myself exposed.<br />
<br />
I'm going to say a big thank you to all of you for following this blog over the last 3 years. It's been a roller coaster ride with lots of ups and downs at various times. The comments that many of you have made have been a big help - and I'm so greatful that you made the time to read it. I want to offer a big thank you to the SAP Mentor guys who showed that there are people out there that know and care what is happening. Another big thanks to Bill Wood - I appreciated the offer, even tho' I didn't take it up.<br />
<br />
I want you all to know that it's been a great experience writing this blog, one that I would not have missed for the world. I wish you all the best in whatever career you follow and hope that you will all achieve the success that you work so hard for.<br />
<br />
Very best wishes to you all.<br />
<br />
"Sapmesideways"Unknownnoreply@blogger.com9tag:blogger.com,1999:blog-129857922559830319.post-3448470675037227532012-05-13T13:56:00.000-07:002012-05-13T13:56:33.314-07:00The fat lady is warming upIt's been a while since my last post - not because I've had nothing to write about, but due to the amount of work I've had to do.<br />
<br />
A couple of months ago, (just after my last post) we had another issue with a consultant doing work that then caused a problem - I didn't actually see what it was as I was at an overseas site and it was fixed before I got back to the office. But it caused a lot of issues with the system performance, to the point where almost no-one could work again.<br />
<br />
Having gone thru the relevant monitoring information, I could highlight that most of the time our system worked really well - I also had the relevant metrics to show just how bad the performance was in the period when the problem was occuring. Once the problem was resolved, the performance improved considerably - and I was able to highlight that the issue was not a fault of the system. But the senior managers were not happy with what I was telling them and wanted some confirmation.<br />
<br />
They had asked the SI to look at the system the last time there was an issue, but the guy that was sent to site really wasn't a Basis specialist. He checked thru some of the obvious transactions, but didn't really provide any hard facts - he didn't even bother asking for the Earlywatch report which could have given him some hard data. Instead, he just told them that the system was not powerful enough - we needed more processors, more memory, more network cards - basically more of everything.<br />
<br />
Now over the last few years, the SI has been quite agressive on the mergers & acquisitions trail - I know that they have acquired at least 3 other companies, and I think that one of these has a stake in a data hosting facility. Last year, the directors from the SI took our shareholders to a junket at a country club, and I'm pretty sure that they were really just promoting the concept of us moving to the hosted system that is now part of their business. <br />
<br />
I understand that the shareholders were told lots of things about how great the service is and how affordable it could be. I've also discovered that it was suggested that with a hosted system, I would not be needed, and if I was no longer around, my wages could pay for this - I'm not sure how much the SI thinks I get paid, but I know that if they got rid of the entire IT department, it still wouldn't pay for the hosted system. Added to that, I still have my doubts about how good their service is likely to be.<br />
<br />
As it happens, some weeks ago I met up with a guy that is a Basis consultant - he is self employed and has worked for some of the biggest organisations around. I managed to get authorisation to get him in for a couple of days and he has gone over our systems very carefully and provided a detailed report on what he found. <br />
<br />
What was clear is that we are not doing too bad - there were a couple of minor tweaks that he suggested might be of some use, but he primarily said the system is well maintained and has sufficient capacity for what we need for the next couple of years. He also highlighted where some of the consultants from the SI have not been following best practice, something that has been annoying me for ages.<br />
<br />
But even with all of that, it seems that the decision has been made to go to a hosted system, even if they will not actually come right out and say so. I don't know if there is a timetable yet, but based on a couple of comments, it would see that they are planning to move the systems sometime around the early part of next year - based on how the SI have done in the past, I might suggest that it won't actually happen until the later part of next year.<br />
<br />
As you may guess, I was not too pleased to hear this. I have in fact approached the CEO and other directors to see if anyone will explain what is happening - but they seem reluctant to discuss in too much detail. However, they won't deny it either which does make me feel very unsettled. I even put my concerns in writing, highlighting the costs and potential concerns - but still they won't talk to me about any plans they might have.<br />
<br />
I must admit that after the problems we faced at the beginning of the year, I sat down with the family to talk about our options for the future. My oldest daughter is at that age where it might cause some issues if we had to move, but they are all aware of what is happening, and they do actually support me. They would obviously prefer to stay here, but if we have to move, so be it. I started brushing off my resume and sent it off to the various agencies. I've also been networking like crazy over the last few months, trying to see if anyone knows of any decent vacancies. <br />
<br />
Since March, I've actually had 4 interviews - and they all came back really positively. But so far, nothing yet..... But I am hopeful that I will hear something this week - fingers crossed. Whatever happens, I will let you know.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-129857922559830319.post-90276511710622062712012-03-25T13:34:00.002-07:002012-03-25T13:34:14.689-07:00Monday morning bluesOn Monday morning, I was on my way to work when I was called on the cell phone asking if I knew that the Production system was running slow. I didn't, but said I would look at it as soon as I got in. While I was getting set-up I had a couple more calls from people to tell me that things were not going well.<br />
<br />
When I eventually logged on, I saw that there was a job that had been running since the Friday before - and it was logged as being one of the consultants that hadn't been on site for some time. I asked around and eventually was told that this particular consultant was due to be on site - he had been organised to look at a particular issue. <br />
<br />
When they guy actually arrived, he looked thru the system and checked out what was going on. It turns out that he had started this job remotely because he needed to check on some data - he thought it was going to run for maybe 6 - 8 hours. Instead it was still running after 60 hours and only finished later that day. It also didn't do what he wanted.<br />
<br />
After he did some further checks, it turns out that a change had been made to the system that would actually cause an issue with the program that he had tried to run. No-one knew about the details as the guy that made the change is long gone, out of the country and there were no references to the work anywhere. In fact the consultant onsite wasn't entirely sure what change had been made. He did say that it had only been done in the production system - there was no transport for the change, and when he tried his program in the Dev system, it ran OK.<br />
<br />
It now appears that we are going to have to pay to get one of their guys in to look at this now - they need to try to figure out what was done and then first correct it, and second, try to do whatever job it was supposed to do properly. I asked if the work would be FoC (well it was their guy's mistake) but no such luck. In fact, they don't actually know how long it will take to investigate the issue - possibly 4 -5 days which we will have to pay for before they tell us how much it will cost to fix.<br />
<br />
This highlights a couple of points. First of all, most of the work that the SI has done has never really been documented, even tho' that was a point raised right back at the beginning. We were told categorically, that they would document all changes that were made - in fact, we have very little evidence for any of their changes.<br />
<br />
Another major issue, is that a lot of the work has never really passed any form of Quality Control gateway test. Again this is an issue that was raised on many occasions, and we were assured that we would have the power of sign off on everything. Yes there have been items that we have signed off on, but there are a ton more that we haven't. In some cases, we don't know that work has been done, and are only finding out when things go seriously wrong, and investigation uncovers the root cause.<br />
<br />
I've spoken to numerous people and the documentation that we have been given by the SI right thru the business is so poor as to be virtually useless. We have very little information on a lot of the changes, and it's difficult to see what we can do now other than get a specialist in that can uncover some of these, and hope that we can get them documented in future.<br />
<br />
I've also highlighted that they often ignore good practice - and here was another example. A change was made directly in the production system without having been tested in the other systems. I'm also concerned that some of our people have learnt these bad habits - I regularly get asked to do something directly in PRD, and if I refuse and point out the correct procedure, I get an argument that the consultants do it that way.<br />
<br />
We should have had a proper change management procedure enforced from the beginning, and I will say that when I queried this, I was told that SAP had a robust procedure that the SI staff would follow. There is a procedure, but the consultants don't bother to use it, and it sometimes seems that they see it as a PITA to be avoided rather than good practice to ensure that we don't get problems.<br />
<br />
For me tho' the big issue is that all of these problems are completely avoidable - there is simply no excuse. I wish that I had a way to identify just how much of the money that we have paid has actually be wasted on work that does not do what it should, or has never been tested correctly. <br />
<br />
I just hope that we don't get off to another poor week this Monday.Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-129857922559830319.post-39659783878282499592012-03-16T15:38:00.001-07:002012-03-16T15:38:25.826-07:00Moral musingEarlier in the week, Greg Smith of Goldman Sachs quit his job. This was a high profile position, and he had a lot of experience, a great deal of authority and was earning a considerable sum of money - yet he felt that he could not continue working there. He arranged for a letter outlining his reasons for quitting to be published - if you want to read it, there is a copy at this link. <a href="http://www.nytimes.com/2012/03/14/opinion/why-i-am-leaving-goldman-sachs.html">http://www.nytimes.com/2012/03/14/opinion/why-i-am-leaving-goldman-sachs.html</a><br />
<br />
I know exactly what Greg was writing about; some years ago, I worked for a company that was doing some things that were morally wrong, and once I realised the situation, I couldn't get out quick enough. But it's always going to be a difficult decision, and I think that he has shown some considerable moral fiber and courage in doing it so publicly.<br />
<br />
I have to say that I understand his views and that he is probably doing the honorable thing. I doubt that he will suffer too much - no doubt, he has saved enough to be able to stay off welfare and he may even find that there are other organizations that will be prepared to offer him something as his knowledge will be highly valuable. But it got me thinking about my reasons for doing this blog, so I thought that I would go through them again.<br />
<br />
First of all, I will say that when I started writing, it was quite simply to vent my frustration at what I saw was a project that was in serious trouble. Having been a project manager in my past, I was not happy at the lack of communication between the SI and the project team. I could see that work was not getting done on time, project milestones were being missed or ignored, and I had serious doubts about the abilities of the various consultants that were working on the project. Even at that stage with limited knowledge of SAP, I could see that the quality of work being completed was poor at best, and the knowledge transfer was almost non-existant.<br />
<br />
However, I am more of a positive person by nature (honest!) and after the first few posts, I wanted to try and make the blog more of an objective analysis of what was happening. I felt that if I could highlight some of the key issues, then others might see these and perhaps this would help them to avoid similar issues in their own projects. <br />
<br />
I've kept the blog anonymous - quite simply, if I identified myself, the company that I work for or the SI, I'm pretty sure that before midday of the next working day, I would no longer be working in my current position. I might also find it difficult to get a new job - with the current climate and an ex-employer that won't provide a reference, it would be a bad situation. Although I do have some money put aside, it's no where near as much as Greg Smith - I simply cannot afford the grand gesture.<br />
<br />
I will also say that I accept some of my writing is about my opinions - other may look at the same situation and say that things are not as bad as I make out. While I may think that some of the consultants working on the project are not doing their jobs well, that is just my view, and as I can't give them the right of reply, it would be unreasonable to identify them too closely.<br />
<br />
I do try to provide an objective view, but in order to keep my anonymity, I have done things such as change dates and sequences of events so that it would be harder to positively identify myself or my company. I don't believe that any of the changes I have made would make a huge difference, but I feel that it is right to make that point clear.<br />
<br />
We have an SAP system that is working and thanks to the hard work of the various members of our project team, it is doing a lot of what we wanted. There are still areas that are not entirely satisfactory, and we are working on those - as far as we can, we are trying to build up our internal skills so that we can rely on our own people. If we mess it up, then it will be no-one's fault but ours, and if the consultants want to come back and laugh at our attempts, they are welcome to do so.<br />
<br />
There is a possibility that I may come across as arrogant - I take pride in my work, I like to think that I am damn good at my job, and I can point to the fact that the IT in the company is light years ahead of what it was when I first joined them. I've had a number of people visit from outside, and they are generally very impressed with what we have achieved - we are way ahead of the curve for a business of our size. But I don't believe that I have the answer to every single problem, and I am willing to listen to ideas or advice from anyone. <br />
<br />
Hopefully, this blog will be a useful resource for some people - if just one person finds something in my writing that helps their project in some way, I feel that it will have been worth it all.Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-129857922559830319.post-61472998210889279262012-03-12T13:50:00.001-07:002012-03-12T13:50:33.062-07:00Still plowing on...I've been tied up with work again over the last few weeks. Sometimes, it seems that the more we do, the less we have achieved.<br />
<br />
We are still having problems with our first overseas site. It appears that there are still items of data that have not yet been loaded. Some of the information for foreign language descriptions of products already in the system, some of the purchasing information records, contact data and even some banking data amongst others. Note that I did ask the question more than once and was told each time that all of the data load had taken place.<br />
<br />
I should also highlight that none of this data load has been tested in the Development or Test systems - they gave up doing that a couple of months before New Year, and the data load is being done directly into the Production system. Of course, it will do a couple of items, then fail because something is wrong with the actual data (which I accept is down to us) - but then they just correct it and carry on as if this is the most normal thing in the world. When I suggested that it might be better to at least try in the test system, I was told that was a waste of time.<br />
<br />
As for data in the Test and Dev systems - It's been agreed that we are going to sort that out by doing a client copy. The last time that was done, it took more than a week to complete and we had all sorts of issues for a couple of weeks after. I hope that we don't get the same this time as I am trying to do a number of other projects and my staff and I will not have time to fix any issues.<br />
<br />
Anyway, a couple of weeks ago, we had the guys from one of the other overseas sites visit with us, so that they could see how the SAP system works. I was told that we would see their whole project team, but only 3 people had travelled over. I've since had a chance to speak to the VP for the site, and made some points to him about the need for a full project team - I also put together some descriptions of work required which have been sent to him.<br />
<br />
I've been asked to go over to them next week to talk to their people in a bit more depth. It turns out that they have been promised that our project team will all be available to help out, which is going to be a shock to most of those guys, as no-one has discussed this with them. I've received an invite to a meeting in April and I think they will all be told then - I've been asked not to discuss it with them yet.<br />
<br />
There is also another issue that is causing a lot of anger. When we first started, the consultants set up a process within the Sales area that did not work the way we wanted - they told us that was how it had to be and was considered "best practice". How we wanted it to work was just not possible. Once it was working, they found some problems and we had to get a couple of people in to fix those.<br />
<br />
When the new set of consultants were working on our overseas site, they set things up so that the process worked the way we wanted - and they said that was actually the way they normally do it. They couldn't change the process for us at that time, but have now agreed a date to do some work to re-do some things so that our Sales people can use the same process in the same way.<br />
<br />
To re-cap - we paid for about 4 weeks to set it up, then another 2-3 weeks to "fix" it, and now we will have to pay for another 4 weeks to change it to work the way we wanted in the first place. I wanted to challenge them over this, but I've been told that we will just have to suck it up and pay the money.<br />
<br />
The best thing - I've recently had an email from the SI asking if I would be prepared to recommend them! They want to use our site to show a "highly successful" implementation, and possibly even use us as a case study. Astonishing!Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-129857922559830319.post-7225927481694535382012-02-20T12:55:00.000-08:002012-02-20T12:55:35.883-08:00The Security Stuff (part 2)I'm following on from last week's post - because I think that there is a bit more to say about this topic.<br />
<br />
If you follow any of the people that promote the concept of "Empowerment" within a business, you'll no doubt be aware that many of these people or companies are talking about allowing staff access to more of the information held within their systems, so that it is easier for decisions to be made at lower levels, rather than having all decisions coming down from the top. This is also sometimes described as "agile" business decision making.<br />
<br />
There is something to be said for this idea - if someone has to purchase some goods, and has been doing the job for some years, she may well be quite capable of negotiating the right kind of deal without having to refer it to her line manager. This then means that the manager is left to deal with more important issues - and when I was a younger manager, it was known as delegation. A senior manager once told me that if you cannot delegate, you cannot manage.<br />
<br />
The problem is of course that not everyone is entirely capable of making decisions at certain levels, and need to be monitored more closely than some others. It also has to be said that there are more than a few managers and senior executives that would be horrified at the thought of more junior people making even quite minor decisons without referring to them. Even if all they are doing is glancing at an email and then replying "do what you think best", they feel that they are "managing the situation". (A bit like the PHB in the "Dilbert" cartoons!)<br />
<br />
So it's necessary to decide how you want to secure your date as well as how you need to secure your data (the two are not the same). How you need to secure the data is often defined by regulatory compliance or the need to prevent commercially sensitive information from going astray. How you want to secure the data is more about how you structure the business and how the various processes work.<br />
<br />
Most people would agree that when SAP was first created, the main target was the larger enterprise business. Within this size of business it is generally necessary to provide some separation of duties - you don't want the person that creates a new bank account being able to transfer money, otherwise he might create an account for himself in the Caribbean and transfer $10 million, before taking a one way flight to his retirement (which he also puts on expenses!).<br />
<br />
As a result, much of the way that things are structured in SAP security has been done specifically to provide the required levels of security for those large organisations. The problem is that when you get to the smaller businesses like ours, it's actually much harder to define what you need in terms of security. Worse, this can actually change a lot more frequently as staff will often be doing more types of jobs than their counterparts in the enterprise business.<br />
<br />
Now we have a problem - I've been trying to make sure that all of the permissions are properly set-up and correctly tested, but even so, sometimes it's not always easy to do this. I will hold my hands up and admit that there have been many occasions when I was going thru a role and suddenly spotted something that didn't look right, that then needed to be corrected. <br />
<br />
Partly this is due to some people taking the view that "give them access to everything, and we can take away what they shouldn't have". This doesn't work - why? Because the only time that you find someone can do something that they shouldn't is when they have done just that, and it has caused a problem. And usually, that is when things are going seriously wrong.<br />
<br />
We have seen that, not just the one time, but on a number of occasions. Most recently because we have some transactions that were created for us by one of the consultants based upon standard SAP t-codes. Unfortunately, the new t-codes have absolutely no authorisation checks built into them - and as a result, we have found that some people are able to do some work that was supposed to only be done by the Production Manager once a day to clear up any issues. <br />
<br />
Oh, and in case you wondered - when I said that I would take the offending t-code out of the role, the Production Manager asked me to leave it in. He is going to speak to staff to try to make sure that they understand that they shouldn't run this particular process, just use the t-code to look at the data. Yes - I'm sure that will work (until the next time).Unknownnoreply@blogger.com25tag:blogger.com,1999:blog-129857922559830319.post-27295856446235648572012-02-12T11:32:00.000-08:002012-02-12T11:33:36.580-08:00We'll do the security stuff later.A couple of days ago, there was a question posted on SDN about security, that got me thinking about how this had been handled during our implementation. If you haven't seen the question, here's a link and I would suggest that it's worth a quick look.<br />
<br />
<div id="AOLMsgPart_1_32dc4880-636b-4c82-a763-78581e0b8406">
<a __removedlink__1191902871__href="http://forums.sdn.sap.com/thread.jspa?threadID=2133938&tstart=0" href="http://www.blogger.com/" target="_blank">http://forums.sdn.sap.com/thread.jspa?threadID=2133938&tstart=0</a>
<br />
</div>
<div>
</div>
<div>
Now I am not a security specialist, altho' I have taken a couple of SANS approved security certs. When I was told that we were going to be implementing SAP, I got talking with one of the guys from the training course that I had done, and he was a bit dismissive of SAP security. He made a comment that SAP security was based upon "security by obscurity", and said that he had never met an SAP consultant that even understood the basics of security.</div>
<div>
<br />
</div>
<div>
When I had the chance, I asked the SI senior managers if they worked to ISO27001 - they were happy to say that they did and had been fully accredited. Subsequently, this proved to be less than true - they did not actually know what was involved in the accreditation process, and as far as I can tell have never undertaken any of the work that would be required. (I should also say that they also claimed to have a couple of other accreditations that they are not entitled to.)</div>
<div>
<br />
</div>
<div>
When we started work on the project, their Project Leader got me started on creating user accounts, and some basic roles - but only really very simplistic stuff. As we started testing, I found that some of the things that I had been told to do were completely incorrect, and I had to make use of SDN and some other resources to identify just where I was going wrong. Later I also did the ADM940 course which filled in a number of gaps, and I've since also done ADM950 & ADM960. </div>
<div>
<br />
</div>
<div>
Now I'm not going to say that this makes me a security expert, far from it. There are a lot of people out there that have a great deal more experience with almost no paper qualifications - and I would be happy to learn from them. But the work that I have done within the training that I have undertaken does give me a level of confidence to be able to say that our consultants really did not know some of the most basic requirements of good security practice. And from what I have sinced learned, they don't seem to be in the minority.</div>
<div>
<br />
</div>
<div>
The quote at the head of this post is an actual comment from one of their guys - and for me, this shows a real lack of appreciation of what security is really about. For security to be of any value at all, it has to be built in from the start - trying to bolt it on after the work is done is quite simply never going to work. A bit like having a high powered sports car, and trying to add wide wheel tires to give it more grip - it will just never do what it should do.</div>
<div>
<br />
</div>
<div>
We are fortunate - we don't have to conform to the level of compliance that a lot of other businesses have to. We get audited once a year and we have a couple of specific checks done, but that is all. I would say that's a good thing for us - if we had to go thru some of the bad practices to correct them, I'm fairly sure that we would still not have gone live.</div>
<div>
<br />
</div>
<div>
Security is not just about PFCG and SU01 - it needs to involve so much more within the software, but it also should cover physical access to servers, workstations and other devices, good working practices, and a structured approach to everything that has to be done within the system administration and management. We've seen first hand what can go wrong when this is not done in the approved manner, and the big problem is that when you're trying to fix a problem after the event, you often only treat the symptom, not the cause.</div>
<div>
<br />
</div>
<div>
I will say that in most cases, we never really knew who some of the consultants were that we would get from one month to the next. We never saw any information about them or their skills - I'm not even sure if the SI even bothered to check on those either. Heck, I'm not even sure if they checked to see if the person that came to site was the person that they employed!</div>
<div>
<br />
</div>
<div>
I can understand that for some people, the drive to get the systems in and working is the top priority, and everything else is secondary. But security should be something that is fundamental to any good system, and it should be in place from the very beginning of the project. Until it is given that level of attention, it will never work the way that it should. And that is only ever going to reflect badly on SAP, no matter who is really at fault.</div>
<div>
</div>Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-129857922559830319.post-16048658964419264202012-01-29T07:58:00.000-08:002012-01-29T07:58:32.398-08:00We don't know, what we don't knowI'm going to go back to the beginning of our SAP implementation project. That was over 4 years ago now, and at times it seems like it was only a very short while ago - at other times, it seems like we have been doing this forever.<br />
<br />
When the original plans were put forward, it was made very clear to everyone that this was not a normal IT project. Although there were some technical issues that only IT were getting involved in, the majority of the work was actually to be done by staff from across the business, and would involve people at all levels, in all departments. We knew that it would take time, and altho' the SI promised otherwise, I was fairly sure that it would take a lot longer than planned.<br />
<br />
An ERP implementation (of any flavor) is always going to be a much bigger task than most others - it requires a lot more work because so much of the product integrates data and processes, and it is important to make sure that what happens in one area, doesn't impact on another. There are many things to consider, and even for those businesses that have a clear understanding of what they do and how they do it, the implementation project is going throw a few curve balls into the mix.<br />
<br />
Added to that, most ERP products (including SAP) will have specific ways of doing things, and it is important to learn how to do these correctly. With most software programs, it's possible to buy a book, work with a demo verison and learn all you need - OK, somtimes, you also need to undertake specialist training, but with an ERP product, this is just not practical due to the size and complexity of the program.<br />
<br />
For that reason, it's necessary to buy in the expertise required. Some companies will do this by hiring extra staff that have had previous experience, sometimes on a permanent basis, but more often as contractors. A more common approach is to use a System Intergrator (SI) which will be a organisation that has prior experience of working in the specific area with the particular product. The really big companies will use one of the big consultancy firms - for the SME type business like us, it's more usual to make use of the medium size or smaller SI.<br />
<br />
The idea is pretty simple - the SI will supply people (consultants) at a set rate that have the required expertise. These people will then help us implement the software by providing technical expertise, passing their knowledge onto our staff, and guide us thru the various steps. This should reduce wasted time, enable us to get up to speed quickly, and ensure a succesful project. Well, a good idea in theory!<br />
<br />
The problem is of course, that when learning new stuff, you don't know just what you need to know. Certainly if you have been involved in projects, you will have an idea of good project management practices - if you have worked with larger companies, you will understand the need for good communications and dissemination of information. You may even know how to manage project teams and stakeholder requirements. But in the case of SAP, if you have not worked with it previously, it is unlikely that you will know much about the practices required by that product, which is why people buy in those consultants.<br />
<br />
That of course presumes that the consultants do know the stuff that we don't know and are willing and able to pass that knowledge on to our staff. Unfortunately, as we have seen that is not always the case. As you might imagine, after the issues that we have had to deal with over the last few weeks, there was a meeting to identify what happened and how to prevent it happening again. At the meeting, it was pretty much agreed that the problem was caused by the consultants not following proper procedure - the procedure which they are in fact supposed to be teaching us.<br />
<br />
Of course, the SI dispute this - their people are doing their job and trying to help us by getting the work done as quickly as possible. Their arguement is that it is down to us not following correct procedures and incorrect testing of the work.<br />
<br />
I will say that I would not totally disagree - I don't think we always do all of the testing that we should. We also should have the settings locked down much more than they are specifically to protect us from this sort of thing happening. But the problem is that if their people don't set and follow correct procedures, how can our staff know what is or is not the correct way to do something? What's worse is that if people learn bad practice, it is generally much harder then to change the way that they work.<br />
<br />
Well enough for now. There are going to be some meetings in the next few weeks, and these will have an impact on what we do next. I am actually looking forward to it, altho' I suspect that I may not feel so pleased afterwards!Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-129857922559830319.post-16904941064234321862012-01-24T12:39:00.000-08:002012-01-24T12:39:50.982-08:00Spoke too soon...I did say last time that we had fixed the issues caused by some bad config changes, and that we should be back to normal. Unfortunately, I jumped the gun a bit - we were still having some issues right up to the beginning of the week.<br />
<br />
To be fair, these were mostly smaller issues - someone found that they couldn't post a purchase order because one of the items on the list had some mis-matched data. There was a similar issue when the guys in the warehouse were trying to assemble some stock to a delivery. Late on Friday, there were a couple of invoices that went wrong - and all of this was from data problems caused by the consultant loading config changes directly into the Production client.<br />
<br />
We've locked the client against config changes now, but in reality, that won't stop it happening again. The consultants have the ability to unlock the client, and there's not a whole lot that I can do to prevent this. I have detailed what we need to do, which is to limit what access permissions they have, but whenever I make that point, the consultants start complaining about being "unable to do their work". <br />
<br />
I will say that quite some time ago, I had the chance to speak to one of the consultants that we had on site for only a few days, and from what she said, it is clear that they generally don't get a lot of support or management when they are working on a customer site. She was quite new to the company, and to SAP, and it was clear that she felt a little out of her depth. She was being asked questions by people from our project team, and all she could do was refer it to one of her colleagues - she just didn't have the experience to handle many of the issues herself.<br />
<br />
This is an item that has been raised before, and I know that a couple of the more experienced guys that are SAP Mentors that follow this blog, have also raised questions about the skill levels of many consultants. A given person may have a valid certification, but without at least some practical knowledge, that person might not be much more use than one of our own staff.<br />
<br />
For me tho' the main issue seems to be that most of the people that have worked on our project don't seem to know much about basic good practice. I understand that time is money, and they want to get the job done as quickly as possible, but cutting corners is usually going to cause problems. Someone else made the comment that you can do it quick, do it cheap or do it right - but not all three, and we have seen that many times. <br />
<br />
This is not made any better by not having any one checking to make sure that these people are following the right procedures. It seems that the SI wants to make that our job - OK, I can see why that is their preference, but at the beginning, we would have no idea what that good practice might be. We know more about it now, but in many ways, it's just too late. They have worked to fairly poor practices, and as a result, we also now have some fairly poor practice in place, and it's not easy to change that.<br />
<br />
Well, we have a few new things being developed now - I won't be able to write about them for a little while, but I think that we have some interesting times ahead.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-424222284043266632012-01-14T04:53:00.001-08:002012-01-14T05:00:08.584-08:00It's broken...<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">Last week, I made a comment that “the consultants
were still working on config changes”, but didn’t go into any details. I can go
back over that now…<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">So I made the point that the consultants were still
making some config changes, and doing so directly in the Production system.
Normally, all changes should be done in the Development system, checked, then
transported to the Test system, before being checked again – and only when it
is proven that the changes won’t cause any functional issues, do they then get
transported to the Production system.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">Now there are certain changes that have to be made
directly in a system as they cannot be transported. However, as far as I am
aware, SAP best practice still highlights that the correct procedure is to make
the config change in the Development system and then once it has been tested
making the same change directly in the Test system. It then gets tested again
before the change is made directly into the Production system.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">The reason for this is simple – if you have a live
system, any change can have undesirable effects. If your business is reliant
upon a system, you want that system to work all the time – you do not want it
going wrong, or working incorrectly. If you follow the correct procedure, you
should be able to ensure that any change made will not turn around and bite you
in the ass.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">But of course there are those people that choose not
to follow procedures because either they don’t know any better, or because they
think that they do know better. (Dare I suggest that some simply do not care?)
In our case, I don’t believe that it is malicious, but I feel that the people
concerned have never had to work to the appropriate disciplines.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">On Monday morning, people found that they were not
able to post anything in the production system. As I arrived at work, it became
clear that we had a crisis on our hands. The CEO and FD were already there,
discussing the problems and trying to get answers on what had happened and why
things were not working.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">After investigation, it became apparent that one of
the consultants had really messed up – the config changes added to the system
were physically preventing any new data from being added and quite a lot of the
older data from being processed. I got everyone out of the system in case a
restart of the server might fix the issue, but that was no good. After many
hours of discussion with the people concerned, it became obvious that the only
way to fix the issue was to reverse all of the changes.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">That work has been going on all week. In that time,
no-one has been able to do very much in SAP – there were a few jobs, some
reports could be run, but not very much. Fortunately, the factory was able to
continue working for several days as we had some info left over from the
previous week, but that dried up after about 3 days. At one stage, the
directors were even considering closing down production and sending people home
and putting plans in place to do this.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">However, by midday yesterday, all of the config
changes that caused the problem have now been undone, and people were getting
down to running the stuff that they had not been able to do. A couple of the
staff from Sales will be working on Saturday and they hope to catch up with
what they have missed – Finance have managed to organise 2 billing payment
runs, and they are staying on for a couple of hours to get the invoices in the
mail.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">Meanwhile, the Production manager has started to run
one of their scheduling jobs, and the Production Supervisor will try to run
another later tonight. I doubt that we will be back to normal by Monday, but we
should be more or less OK by Tuesday lunch time – evening at the latest.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">So of course, everyone is pretty angry about this –
but so far, no word of apology from the SI. The CEO has told them in no uncertain
terms that any attempt to bill us for the work will be rejected. I think that
we ought to get some sort of compensation, but based upon their previous
mess-ups, I think that is highly unlikely to happen.<o:p></o:p></span></span></div>
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;">
<span style="font-family: "Times New Roman","serif"; font-size: 12pt; line-height: 115%;"><span style="font-family: Times, "Times New Roman", serif;">So we have managed to escape a major disaster<span style="mso-spacerun: yes;"> </span>–<span style="mso-spacerun: yes;"> </span>yes,
things could have gotten a lot worse, and other people have suffered far worse
things that we have. But I do feel that we should have not been exposed in that
way to begin with, and I do get frustrated that we are suffering because of
other people’s behaviour with apparently no recourse to compensation.</span> <o:p></o:p></span></div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-129857922559830319.post-12028340450113861472012-01-08T08:26:00.000-08:002012-01-10T04:59:27.863-08:00Not so happy new yearThe new year has come and gone; so our overseas site must have gone live, right? Unfortunately, no.<br />
<br />
Although we technically stopped work for Christmas, I was getting emails and phone calls right thru the holidays. I started to feel a little concerned as it looked increasingly like they were struggling with some basic stuff; and on New Years eve, I got a call to tell me that the go-live was postponed until the end of January.<br />
<br />
Despite the fact that I had asked many times if the data had all been loaded (and been told that it was), the actual situation is that there are still a number of items of master data that have yet to be loaded. Little things like a load of customer and supplier information, bank details, a lot of product information and the open activity etc. <br />
<br />
On top of that, the consultants were still working on config changes (more on that next time) up until Christmas eve - but then stopped work until the first week of January, and so there's a substantial number of items outstanding that haven't even been looked at.<br />
<br />
I was asked to go over to the site along with the VP of operations - we had a really bad flight over, then problems at the airport with a lost bag. This delayed us getting to site by several hours, which was made worse by the cab driver taking the wrong route.<br />
<br />
By the time we got to the site, he was not happy at all. The consultants were watching some video on a laptop and howling with laughter which really did not sit well with him. When he spoke to the consultants, he made the point that he had been told that everything would be ready, and the delay was down to them entirely. He also said that he did not see why we should continue to pay their company if they were not able to do the work that they themselves had agreed to.<br />
<br />
Subsequently, he had a conversation with the director of the SI - who didn't apologise for any of the issues or the delay, but suggested that our VP should apologise for being too demanding! To be honest, I stayed out of it as much as I could - but the conversation we had at the hotel that night showed that our VP is not impressed, and I think that he will not leave this point alone until he gets satisfaction.<br />
<br />
So, we spent a week on site, going thru the outstanding items, and trying to get these covered off. Surprisingly, we did manage to get a lot done while I was there, and altho there are many areas still not finished, we could be on track and be ready to go-live in about another 3 weeks.<br />
<br />
I will say that I am still a bit concerned at the moment. The consultants have the staff at the site doing some training - by entering data into the live system. Now I accept that it is live data (from real orders etc.) but this should be done within the test system, not the production system. But hey, what do I know about anything.<br />
<br />
Some of the results they get are not quite right - well that's to be expected if it's not been tested as it should. They have had to go thru some of the data to make amendments, and they had to make a couple of other config changes that had been put into the test system, but not the development or production system. Before you ask, they still haven't put them in the dev system.<br />
<br />
So here we are again - waiting for work to be done that I was told categorically had all been finished. I am planning to go back over again in a couple of weeks, but possibly that may be sooner. I'll try to keep you updated.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-129857922559830319.post-16338669534323271012011-12-22T06:57:00.001-08:002011-12-22T07:00:14.006-08:00We have definitely been here before!We are rapidly approaching the point for our overseas site to go live – they are due to start using the SAP production system starting on the first working day of the new year. As we only have a few days left before Christmas, there is not a lot of spare time.<br />
<br />
The data loading process has been going on for some time now - I asked about how they were getting on a while ago. I was told that it was all done – but when I pressed a bit harder, it was admitted that there were a few items not quite finished. (Such as bank details, purchasing info records, part of the master material, some of the customer’s data and some other equally inconsequential items!) The work to load this is still going thru, but I would not be surprised to find it incomplete on day 1 of their go-live.<br />
<br />
It also has to be said that there are still some items that have yet to be configured. Two weeks ago, it was agreed that we would stop all further changes in order to concentrate on the data load. It was suggested that I would do any further role change requests, as this could be arranged at a time when there would be no issues with processing the transports (as it happens, there has been no need for this). However, one of the consultants apparently didn’t get the message – a change was made, pushed thru without reference to anyone and a whole day was spent undoing some of the issues created.<br />
<br />
In the mean-time, the SI has sent a letter of complaint that caused some internal discussion. There are a lot of bills that they have submitted that our FD simply will not pay. Of these, more than half are for work they say was done, but that we have no evidence for. For example, they had a person on site for several days over a 3 week period according to one bill, but the person concerned had left their employment and was working in a country on the other side of the world on the dates that they supplied. There have been items for 100s of miles of travel and a night’s accommodation for the same day. Just to really stick the knife in, they also changed the agreed daily rate billed on some of the items – and when the FD asked who had authorised this, they were unable to give him an answer. <br />
<br />
Over the past few months, I have also been trying to look at ways that we can make more use of our SAP system. It seems to me that whatever I might think of its capabilities and shortcomings, having spent as much money on the project as we have, we should try to make sure that we get the most bang for our bucks. There is a specific process that one of the managers has been wanting to do for several years, and altho I have a few concerns about it, it seems that this could be done within SAP. Part of the work is already done, which is a plus – it would just need slightly more data being entered than before.<br />
<br />
His concern (and it is a valid one) relates to the output – he wants to do specific things with that, and it was subsequently suggested that it could also be used to improve some of the data provision to customers. These are all very consistent with company strategy and I want to encourage him. However, there are some concerns about how it would be done, and at present we don’t yet have the necessary specific skills internally – this would then require we buy in more consultancy.<br />
<br />
Because of those concerns, he has recommended that we look to buy another software product – and to me, this is just utter madness. He wants the company to allocate another $300,000 to fund his project, but what really bothers me is that it would then duplicate the work being done, require more hardware, more software (plus licences, maintenance etc.) and he’s suggesting that it could be at least a year before the project would have any output worth using. Color me crazy, but that does not seem like the best way forward when we have already paid as much for SAP as we have, and could do the job as well by spending a little more on getting some training done. <br />
<br />
So – the holidays are nearly upon us. Decorations are up, the tree is dressed, presents are wrapped, parties are being organised. We seem to have enough food in the house to last for the rest of the winter – I’m told that we are inviting lots of friends & family around this year and we must of course provide hospitality (I don’t remember having THAT discussion!). <br />
<br />
As this will be my last post for 2011, I would like to wish you all a very merry Christmas, and I hope that whatever the holidays mean for you, that you enjoy them in the company of your friends, family or loved ones - and may the New Year bring you all the success that you would wish.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-51469672902582445802011-11-21T16:30:00.001-08:002011-11-21T16:33:41.868-08:00Back to the training boardI've not posted anything for some weeks - mainly because I've not really had anything to add. Work continues as normal, but there has not a great deal happening with our SAP project.
<br />
<br />
The go-live date for our overseas site was put back to January of next year. This should have given us time to get some of the data load done, but very little has been added so far. We still have time, but we are still waiting for much of the data, which is still to be cleaned up.
However, the staff at the overseas site have actually been doing some training, and they have also been testing what data has been added, as well as manually adding some data of their own. I think that this will be very useful as it means that they will be more comfortable once they start using the system for real.
<br />
<br />
One thing that has been discussed in some depth is an old favorite of mine - training. I've said a number of times that I feel we should be enhancing our internal skills by getting our project team members and perhaps even some of our end users to attend formal SAP training.
To me, it makes sense to invest the money in our staff, and retain knowledge within the business, rather than pay consultants who will be here today, gone tomorrow. <br />
<br />
The costs are pretty straight forward - pay a consultant $1500 per day, or get staff on a 2 day training course for about the same money.
I'm not sure how many times I've discussed this with people - probably to the point where I get boring. But I've been on some courses, as have some of my staff, and we know the value of the training, and can demonstrate the benefits. <br />
<br />
To me, it is so simple - and yet our project team haven't seen it that way.
I believe that part of the issue is that I am used to the idea of continuous training - anyone in IT will know the value of this and the need for constantly renewing skills. On top of that, I am also used to the requirement of managing my own training - but clearly, this is not how others see it.
<br />
<br />
However - it seems that my message is slowly starting to sink in. I've recently had a number of members of the team speak to me about organising training, and it seems likely that they will now carry this thru. The only problem is what courses will be of the most benefit and how to make sure that they get the most from the courses.
<br />
<br />
I am aware that if they attend a course and it doesn't meet their expectations, they will be less likely to want to go on another. I'm therefore trying to make sure that we have a very clear roadmap of the appropriate modules for each individual. I'm not so sure about the need for some of the certfication tracks - I don't consider it necessary that we need to get people qualified, but we should try to make sure that the plans follow a pattern that will provide appropriate knowledge in each area.
<br />
<br />
One thing that has been noted - the project team members are a bit more vocal in the way that they describe the lack of knowledge transfer from the consultants. They also seem a bit more prepared to criticize the quality of work carried out, and several of them have highlighted key areas that they want to cover in training that have been those where the consultants did not achieve what was required. I'm not sure that we can do this straight off, but I don't want to put them down too quickly - I'd rather try and keep their new enthusiasm high for as long as possible.
<br />
<br />
I suppose that once one of them goes on a course and then comes back and can confirm to the others the value of what they have learnt, we will then see a sudden rush of the others - well, that's OK as far as I am concerned. We have a decent sized budget now for the training as long as we can continue to justify it, so I want to see it used to best effect.
<br />
<br />
Hopefully, I'll have some feedback from at least one of them soon.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-71887820638151903202011-10-03T14:39:00.000-07:002011-10-03T15:25:24.598-07:00Have we been here before?So - we were supposed to go live at our overseas site today. Up until Wednesday of last week, they were still determined that it would go ahead, come what may. This was despite no more than 10% of the data having been loaded, and we are still waiting for quite a bit of data to be extracted from their legacy system.<br /><br />I only finally got the confirmation of the delay midday on Thursday - it's been put back to December at the moment, but I'm not sure if that will stand either. I know that the site manager is relieved as he was really concerned that they are just not ready, and I believe that most of the staff there are equally pleased. Our project team are not entirely happy - but they all accept that it would be too much of a risk to try and go ahead.<br /><br />Now we have a bit more time to try to resolve some of the issues that are still outstanding - but I'm a bit concerned that we may end up with a few more as well. There have been a couple of config changes made and once again, it has caused us some problems. (Did someone mention testing?)<br /><br />This time it's the purchasing, which is a real pain as that has actually been pretty good for some time now. It appears to be to do with the release strategy - the change means that staff can release purchase orders to any value, instead of the staged release which took us about 3 months to get right. I left the manager in charge of the purchasing department working his way thru a number of items to try and get a handle on exactly where it has gone wrong.<br /><br />The consultants fixed the printing problem on the purchase order - well almost. There's a bit of an issue with the vendor addressing and a number of the POs have completely the wrong details. I got a message earlier today to tell me that there is a specialist going to take a look - it appears that he has already had access to the system, but he's been using someone else's account. I've now created an account for him, and asked him to use that - I've had no response, so I don't know if he hasn't received the message, or just can't be bothered to do so.<br /><br />There was also an issue on the finance side (not quite sure what it was) and they had arranged for a consultant to look at the problem - we were told that it would take them about 4 / 5 days. However, the FD was looking at it, and with the help of a Google search, he has fixed the issue. The SI are not pleased at this.<br /><br />Talking of the SI, I've had one of their people chasing me to outsource the systems to them. This is something that I'm not particularly keen on for a number of reasons. They insisted that it would all be managed in a facility in this country, but when I checked, the data center they use is actually somewhere else in the world - I think it might be either eastern Europe or Malaysia, I've not been able to clarify.<br /><br />Their sales guy insisted that it would be cheaper to use them - well there would be savings in hardware / software / utilities, but I doubt very much that it would work out any cheaper. Some time ago, I looked into the costs, and based upon what we would need, the price from the only hosting center prepeared to give me an estimate would indicate that we would be looking at $300,0000 a year now, rising to $600,000 in about 3 years time. I can tell you, that would be more than our current IT budget.<br /><br />However, it's not just the cost that worries me - this system is going to be the key system for the whole business. A decade ago, it wouldn't have mattered if it went off line for a few hours or even a day or two - that's not the case now. Quite simply, a loss of service of more than a few minutes would be problematic, more than a hour could be disastrous.<br /><br />Based on their performance, can we trust our key system to them? Of course, it's not just the potential loss of service. I don't feel that they have demonstrated that they work in a particularly secure mananer, and I'll be honest, the thought that they might lose data scares the heck out of me. However, it won't be my decision anyway - this is something that the board will decide. Apparently, they are arranging for a junket at a country club for the shareholders and the board, to advise of them how it would work - I have not been invited. <br /><br />However, I have been asked to put together a presentation of my concerns, highlighting the costs. I've also included some statistics on what we have achieved and how much we have saved by doing it all inhouse. In addition, I've put forward some plans for future development that would allow us to ramp up the resources to deal with required increases as the other sites come on line. We'll see what happens.<br /><br />Back overseas again next week. I'm really racking up the frequent flyer miles - next time, I'm taking my wife with me!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-79102878543049055462011-09-25T03:17:00.001-07:002011-09-25T03:17:56.445-07:00I'm Back!I’m back! Before you ask, I had a great time thank you. <br /><br />Unfortunately, the flight back was delayed – and we got home very late on the Sunday. There were a number of messages waiting on the ansafone (I hadn’t taken my cell phone), and essentially, the messages all said that I was to get over to our overseas site asap. So I packed a fresh suitcase, and got my flights booked – with an early flight, the time differences plus the delays the day before, I was really very tired by the evening.<br /><br />I spent the week over there, and then it was decided that I should go back again this last week. What with that plus trying to do my normal work and various other chores, this is the first chance I’ve had to sit down and analyze the situation.<br />I’ve not been told officially, but it appears that a number of staff have been told that the overseas site will not be going live in October after all. I’m not surprised – the data load was supposed to have started the 1st week of August and it hadn’t started by September. Even now, very little data has actually been loaded, and it appears that there are still some unresolved issues with parts of it.<br /><br />During my first week over there, I spent a bit of time doing some training – about half of the staff there had still not even logged onto the test client, and they are a long way from being confident in using SAP. I also had a very upset General Manager complaining that there was a printing problem. When I checked, it was actually only one document that had the problem – the sales order form, so rather important that they gets this fixed. <br /><br />I haven’t done that much work on the smart forms, but I took a quick look, and discovered that one their consultants had made the change. Unfortunately, no-one knows why or what for, and the guy isn’t available. I’ve left it to them to chase up, but so far, it’s still not printing at all.<br /><br />Another issue has also appeared recently that affects the financials. At first, the consultants suggested that it was an authorization problem, but we’ve now identified that certain products are being assigned to the wrong ledger code. Again, no-one is really quite sure why – we have our consultants telling us that the configuration was correct, and their consultants are saying that it’s not. So they’ve made a change and now we have a problem.<br /><br />Our Accounts Manager is really upset about all of this. A couple of times now, she has spoken to me in private, and it’s clear that she is very distressed about the whole scenario. She’s been with the company a long time, and has been thru some really tough times, but I think that this is the worst she has ever felt about her job. I just don’t know what to say to her anymore.<br /><br />I’m also a bit concerned about the amount of testing that they have done. If you’ll remember, a bunch of us went over back in April, and we did some full end to end testing of processes and made sure that everything worked – but that was only using a limited amount of test data. <br /><br />The guys on site have access to the test system and although not all of the live data has been loaded, about 80 – 90% is available. But the testing that they have been doing is not the same end to end testing. Yes they have put a whole ton of quotes, purchase orders, sales orders on the system, but they have not then followed this thru to make sure that orders appear on the MRP or that sales get billed.<br /><br />It could be argued that we shouldn’t need to test again, as it was proven to work in the development system and we are using the processes in the production system. But the issue is that their consultants have made a few changes and I strongly feel that we can’t be absolutely sure that any of their tests would actually work unless we do try it out.<br /><br />I did manage to speak to the GM of our overseas site one evening over a beer – he is very much of the opinion that they will not be ready for the start of October. He did suggest that perhaps they could have a staged approach to the go-live, perhaps by working in tandem on both systems. I wouldn’t have a problem with that in principle, but they don’t have that many staff, and I’m not sure they could actually do that.<br /><br />Oh well, back in to work tomorrow, and maybe I’ll find out a little more about what the plans are.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-80723819730401982532011-08-20T12:49:00.001-07:002011-08-20T12:49:48.127-07:00Problems with pricesAbout 4-5 months after our go-live, I received a request for a change to a role. At that stage, we were still making quite a few changes as we discovered issues that had not been uncovered during the testing phase. This was quite normal, but something about the request didn’t seem quite right.
<br />
<br />The particular role was one that I had worked on with the sales manager, and the request from our second site seemed to indicate that there was a problem that should have affected everybody. When I went into it in more detail, I wondered if it was due to the staff concerned not entering the correct information.
<br />
<br />I passed this back to the relevant key user from sales, and she confirmed that the process was working for each site – it seemed that this was an issue with staff training. So the sales manager organised a quick refresher session with the sales staff at the second site.
<br />
<br />Whilst he was going thru this with them, he also spotted an issue with the cost price of one item that they were using. Quite simply, the cost price shown in SAP was way out – in fact, even with the price uplift, they were actually selling the item at a loss of about 25c each for a selling price of just under a dollar. He then started checking a few other items – most were OK, but there were more than a few with a price that was wrong.
<br />
<br />Subsequently, they spent some time going thru the rest of the price list to make sure that this was OK – and based on what he found, the second site had lost just under $10,000 in incorrect pricing during those first few months due to an incorrect price having been loaded during the data load process.
<br />
<br />An investigation proved that the price had been wrong in our old system. At some stage, the price had gone up but never been altered in our old ERP system. No-one knows how much we lost in total, but most agree that it’s probably over $25,000 for each of the previous 4 years – a total of at least 100 big ones. You can imagine that there were some people that were very unhappy about this.
<br />
<br />The reason I raise this now is that we were doing the training with our overseas site just over a week ago, and it appears that they also had the same incorrect prices in their old system. This has caused some real upset as people are trying to uncover when things went wrong and why. I doubt that we will ever know.
<br />
<br />Of course, one thing we can say is that is not down to SAP. The problem occurred long before we started the implementation. It could be argued that this should have been picked up at the data cleansing phase, and that’s probably true – but it wasn’t. No matter what anyone thinks of the software, there is a limit to how much it will cope with the failure of the human element.
<br />
<br />So chalk one up for SAP – while the correction of the price won’t cover the costs of the software, it’s identified a major problem that has taken money off the bottom line, and one that would quite possibly not have been discovered for many years. Although there are still questions about getting an ROI for the project, each of the areas where it has made a difference will help to justify the decision to buy it.
<br />
<br />Oh well, vacation time is here. I feel that it is overdue, and am looking forward to a good break.
<br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-39167451643792677562011-07-30T14:56:00.000-07:002011-07-30T14:57:27.428-07:00None so blind...I started to write this item a couple of weeks ago – but didn’t finish it at the time. I was highly annoyed and wanted to think about things before posting.<br /><br />We actually started work on the SAP rollout at our overseas site almost 2 years year ago. However, nothing was ever completed, even in the development system and eventually, the project stopped before being started again with a new set of consultants in the middle of last year. The plans then were to go live at the end of October last year – as the previous consultants had done quite a bit of work, it was felt that this was achievable.<br /><br />However, it quickly became clear that most of what had been done was of no value. Essentially, it all had had to go right back to the very beginning. The SI were still trying to say that October 2010 was achievable, but most people on our project team could see that was never going to be possible. A date was set for the end of July this year – most people agreed that this could be done if all went well.<br /><br />As it happens, in April of this year, the consultants still had not finished working on the development system. We also had issues because almost no testing had been carried out, and absolutely no training had been done either. Our project team then went to the site to do some work, and as I’ve indicated, we managed to get a great deal done. So much in fact that we all thought it might still be possible to go-live in July. There is still major work being done by the consultants, but from experience, it seems to be normal for them to still be working on items right up to (and even after) the go-live date.<br /><br />But there has been a major problem with getting data loaded. First getting data out of their existing system has proven to considerably more difficult than anyone believed would be the case. Cleansing the data was also a bit of an issue – but the biggest problem has been getting it matched to the relevant data load into SAP. I had been told by the SI that about 80 - 85% of the data load had been completed into the development system – but during our test phase it became very clear that it was really closer to 10 - 15%.<br /><br />Since then, some data has also been loaded into the test system – but no more than about 30 – 40%. Some training has been done with key users, but none with the rest of the end users. I had to go over there again a few weeks ago, and they were trying to do some testing work in the test system. Most of this failed simply because there was insufficient data to allow more than few test scripts to be used – it took them as much as half a day to complete a single test item.<br /><br />As it became clear that July was slipping away, a decision was made to move the go-live date back yet again. This makes sense, and I have no issue with that other than once again, we are committing many resources to the project than was originally planned. But what has outraged me is a decision that has been made following further discussions with the SI.<br /><br />The director of the SI suggested to our senior managers that we did not need to complete the data load process in either of the development or test systems, but simply go straight to the production system and load the data without having to do any testing. The argument was that we had done a few items so that proved the process worked and therefore any further data added to the same process would also work. He also argued that if we needed to have data in the other systems, it would be easier to do a system copy after the go-live.<br /><br />I tried to point out that this view was completely wrong – we have seen repeatedly that people make mistakes when preparing the data. In some cases, the mistakes are so significant that the data will simply not go into the database without considerable manipulation by the people carrying out the work. To trust that all of the data will load correctly just because you have loaded a few lines is at best, wishful thinking in my opinion. As far as I am concerned, completing the data load process in the development and test systems should then save time and effort when loading into the production system. <br /><br />But there we are – I can do no more than point out the issues and then do my best to see if I can fix the problems when they occur. But I must admit that I am now really beginning to feel that I can do no more on this project. I feel so frustrated all of the time – all I hear is that everything is going well, when it is abundantly clear that things are far from satisfactory. <br /><br />I have no problem people trying to maintain a positive attitude – I can see that sometimes this is a necessity. When something requires such a major business transformation as SAP, it is essential to keep everyone motivated. But what worries me is that we are seeing “ostrich management” – burying their heads in the sand in the hope that if they don’t see the problem, it will just go away. I can’t believe that will be any good for us, now or in the future, on this project or any other.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-129857922559830319.post-33124277382125444482011-07-10T13:13:00.000-07:002011-07-10T13:14:42.265-07:00Eye of the beholderLast week, I had the opportunity to visit the manufacturing plant of another company. These people started to work on SAP a couple of years before us, and I had been told that they had been successful – so I was interested in talking to them in a bit more depth.<br /><br />I had the chance to talk to the IT manager on site – a nice enough guy, although he seemed a little distant. As we talked, he made the point that they had gone live after just 8 months and they had experienced no problems. I won’t say that he was being arrogant, but there was a definite sense that he was as far as he was concerned, their project had gone very well indeed, and he was more than a bit proud of that. When I told him of our project and how long it took, he made me feel a bit bad.<br /><br />However, I also had the chance to their production guys, and they had a slightly different story to tell. A few days after go-live, the system had gone down, and it took a couple of days before it was working again. They didn’t know why, all they knew was that it caused a few problems for them. That was bad enough, but it appears the same thing happened on several occasions over the next 4-6 months. Added to that, it appears that they still have an on-going issue relating to some of the data that they are accessing – they couldn’t tell me why.<br /><br />After that, I spoke to a couple of their finance people. They remembered the first few months as being a complete nightmare caused by a series of issues with billing documents, financial reports and figures just not adding up. It appears that most of these are sorted, but they still recall those problems and again, they are still finding issues on a regular basis.<br /><br />Later when I checked, it seems that there is quite a difference between the size of the projects, even tho’ the companies are about the same size. They have a lot fewer products than us, and there was a lot less to do on data migration. In addition, they don’t use a couple of them modules that we are using – and these items were seen as being responsible for a good proportion of our delays. Possibly our project might not have taken so long if we had been in the same situation as them.<br /><br />When I thought about it later, it seemed to me that this is a case that the individual people were really only concerned about what had happened within their own areas of the business, and the project had been judged by that. As far as IT was concerned, the project went well because it came in on time and budget – the other issues were irrelevant. But for the other departments, they could only see the issues that had caused them major problems. Even years later, they don’t see their SAP project as being that successful.<br /><br />I was once told by a CEO that he liked me because I looked at the bigger picture, and in his experience, most people in IT just didn’t do that. I can appreciate that the IT manager in this case was pleased with the project and felt that his team had performed well – but I could also see that the other departments were not as happy and for valid reasons. OK, they did get things sorted, but it was clear that it could have been a lot worse for them. When I compare that to our project, I don’t feel quite as bad. <br /><br />I think that with an ERP system, it is important that people look at it from an over view rather than just within their own specific areas. If I think back, it seems to me that when things weren’t going well, it was because it was a single person or a couple of people working on their own without involving others. When things went well, it was because we were working as a team.<br /><br />I know that the SI have been telling people that our project was a success – and if you look at it from a particular perspective, they are probably right. SAP is working for us, and in some respects, it has achieved some of the primary requirements. From the company point of view, that’s not the whole story – the project has been very expensive and taken a lot longer than we had been told it would. In some areas there has been no benefit or processes are much more difficult – in other areas, we have seen improvement or there is an indication that we may see this in the future.<br /><br />Essentially, it seems that the quality or success of an SAP project is very much in the eye of the beholder. Personally, I would rather judge on well it achieves the requirements stated at the beginning of the project – but then, that’s just my opinion.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-24679649505912925592011-06-18T11:20:00.001-07:002011-06-18T11:20:56.475-07:00PaperworkRight back at the beginning of our project, I talked to the SI about the need to provide us with detailed information concerning what changes they had made to the system. To me, this is just good practice – any time that someone makes a change to a system, it should be documented. There are a number of reasons behind this – people are not always available to confirm what has been done, jobs change and people move, security and audit issues etc. so good documentation is really important, especially before you start making other changes.<br /><br />The SI promised that we would have full documentation, and they did indeed send us a document once we had gone live. However, it contained almost no actual information on the changes made, other than some flow charts to show processes and was quite a small document compared to the work done. I queried this at the time, and was told that this was standard SAP documentation – when I pushed a bit harder, the guy concerned got really snotty with me. His view was that this was the same format provided to everyone else implementing SAP, and those people had no issue with it, so I should just accept it and stop complaining.<br /><br />I spent quite a bit of time trying to see if I could find a way to uncover what config chnges had been done, but I must confess that with all the other work going on at the time, I simply could not keep track of what was happening. It also became pretty difficult to maintain details of who was working on what, when, why and what they did. We had an issues list, and for the most part, this is now our primary resource for determining what work was carried out.<br /><br />As it happens, when we applied a number of support packages, we found several issues. After investigation, it was determined that some of these (not all of them) were down to config changes having been made, and this caused a number of delays until we could complete various work to deal with the situation. It definitely took much longer to do the updates than it should have, and the delays impacted other work.<br /><br />However, about a year after we went live, we had another consultant on site for a few weeks. When he left, he handed over a really detailed document that we still have – it gave information on what he had done, what changes, what code even. The file was everything that we had previously asked for, and exactly what was needed. It ran to a couple of dozen pages, and was really helpful as we could then refer to it when there was a question about an issue a few weeks after he had gone.<br /><br />As you can probably tell, I think that this is a very sensible and professional way to work. I raise the subject because there is a particular consultant that has been doing quite a lot of work on our systems, and a couple of weeks ago, we found out that he has now left the SI. The trouble is that he has documented nothing – and I mean absolutely zip. No-one at the SI can talk to the guy, and they have no idea of what he had done, or how far he has got with the work he was doing other than at a pretty basic level.<br /><br />OK, we will survive – but it is not the best way of working. It’s just another example of bad practice, and when you are paying about $1500 a day, I think that you are entitled to expect a certain level of professionalism and I am not convinced that we’ve seen that from some of the people that we have had working for us on our project. <br />Having said all that, I would understand if anyone then turned the criticism back on us. The systems are ours, and it would not be unreasonable for someone outside of the company to suggest that it is our responsibility to maintain records of what work is done. As it happens, we do keep some records for various reasons and we can point to a number of audit trails that show we are attempting to maintain a level of control. <br /><br />The problem is of course that in many ways, the SI and the consultants working for them were working in the way that they want to, rather than in a way that matched what we want or need. I suspect that for most of the consultants concerned, this is the same way that they have worked on all of their projects, and they know no different. Our project leader should have forced the issue (and he freely admits that) but he was taking advice from the SI on how the project should run. But we will probably never know all of the configuration that has been done. <br /><br />Well it’s too late now – just got to keep going as we are.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-129857922559830319.post-88195850054968095132011-05-30T13:54:00.000-07:002011-05-30T13:55:54.529-07:00No change here...It’s been about a month since my last post – and there’s a simple reason for that. I’ve been really busy on other projects, not related to SAP. I’m not the only either – several other departments have also been catching up on various things that have been delayed.<br /><br />We started the SAP implementation about 4 years ago. At times it seems astonishing how quickly the time has passed, at other times it seems that we have been working on it for ever. The problem is that during that time, so much effort has gone into the project, that many other jobs have been postponed. In a couple of cases, this has not been a good thing – we needed to get on and get them done so it was decided that we would do exactly that.<br /><br />For IT, there have been a couple of hardware refresh jobs, replacing workstations, printers and a Xerox machine. We’ve also been testing a couple of tablets that we think might be of value to the sales force. There have been couple of jobs done within some of the offices to make more efficient use of the space available, so we were also getting involved in the cable work. As you can see, this has meant that there hasn’t been a lot of time left to do more than basic work on SAP.<br /><br />After the last visit to our overseas site, everyone felt that we had gotten thru a lot of the outstanding work and had almost caught up so that we would be back on schedule. When we left, the point was made that they needed to get on with the data preparation so that it could be loaded. We had done some loading of a few basic data items into the Development system, but not all of the data, and literally only a few items in each category. A decision was made that we would load no more into the Dev system and just go straight thru to the QAS system. <br /><br />I was a bit concerned about this, as I felt that the actual loading wouldn’t really take up that much time, and felt that it would make sense to try to get all of the data sorted and proven. However, I could see that we need to keep on schedule – I’m not happy about cutting corners, but I can probably live with this.<br /><br />However, when the data arrived, it quickly became clear that it was simply no good. Not one of the data loading batch jobs was able to complete successfully, and most were so poor that we were looking at maybe 10-20% had gone in successfully on each batch. It was so bad that the project leader took another trip over there to talk to them again. When he arrived back, he was really pissed – he went back over the requirements with their people but feels that they still don’t quite yet get it. <br />I haven’t been asked if I would go over again, but I know that there have been discussions, and I get the feeling that they are expecting me to offer to go there in the next couple of weeks. As it happens, there is work that I was planning to do, but I’m not sure I will have time to do both jobs, the planned work and talking with them about the data preparation and cleansing.<br /><br />There is no question that it is essential we get the data right. We found this out ourselves when it was our turn. We have made the point to the people at the overseas site, and several people discussed it with them, making the points very clearly. We provided some sample files showing how it should be done, highlighting the main pitfalls – but none of this seems to have made the slightest difference, and they are now well over a month behind where they should be, and falling further behind each day.<br /><br />No-one has said anything, but I’m now a bit concerned that they will cut back on the testing in the QAS system before we go live. I’m also a bit worried that staff over there won’t get the full amount of training before their cutover. For me, it would make sense to push the go-live out again, and make sure that things are done right. But it seems that there is something going on in the background, and they don’t seem too keen to discuss any further delays.<br /><br />Well, we’ll probably know a bit more in a couple of weeks’ time.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-129857922559830319.post-37950261204270184902011-05-01T08:31:00.000-07:002011-05-01T09:15:21.384-07:00What a difference a day makes...Or even a week…<br /><br />Our project leader has been over to our overseas site a number of times so far this year, about once every 3 weeks or so - and altho he has said in the board meetings that things were going well, it was clear that there was a bit more hope than confidence in what he was saying. <br /><br />Privately, he has been suggesting to the project team leaders that there are still far too many issues unresolved, and that despite quite a lot of hard work, we don’t seem to be progressing as fast as we should be. Although he wouldn’t actually say we were behind schedule, it’s pretty clear that the proposed go live date was looking increasingly hard to meet.<br /><br />I’ve suggested a number of times that we should get the staff from our overseas site to visit with us for a week so that we can help them out with training and testing – by getting them to work with our staff I hoped that they would pick up some of the required knowledge. But altho it was seen to be a good idea, we have had none of their staff visit with us since last August.<br /><br />It was then suggested about a month ago that we should arrange for our project team to go over there instead. Plans were made, travel and hotels booked and the project leader set out a plan for the week. This was primarily to test their processes to make sure that these would work – I felt that this would be a good start, but was concerned that we would miss a good opportunity to ensure that their staff was adequately trained.<br /><br />I’d also gotten a bit worried about some of the comments from our project team – one or two had said to me that they were not really sure what they were supposed to be doing over there. So I made a point of spending some time with each one, to discuss how to test the various processes, and I set-up a series of test user accounts for them and made sure that they knew what they had to do.<br /><br />On the first day at the site, we weren’t able to get much done – we arrived late in the day, and really only just managed to introduce ourselves to people, and get things organised so that we could start work properly the following day. But after that, things really started to take off.<br /><br />The project team made a point of getting the key staff in with them so that they could see the processes, and in most cases after a couple of demos, these people were carrying out many of the actual tests. That second day, we had actually gone thru every single process and tested at least 3 variants for each. Their staff are now far more confident in the way that they use SAP, and altho they still have more work to do, based upon what they did last week, they should be ready for the go-live.<br /><br />It should be said that during the tests, we did actually find several key issues – but about half of these I was able to correct almost immediately. As one of their consultants was on site, the rest were passed to him and it has to be said, he made a good start on getting them corrected. However, he also made contact with a couple of the other consultants and they were then available on the third and fourth days.<br /><br />In fact, by the last day, we had not only gone thru every process many times and confirmed all were working, most of the outstanding issues had also been addressed. This included several that have been on the list for months. It also highlighted a couple of issues with data – I had tried to highlight this previously, and now it is obviously the most urgent major problem remaining so they are looking at dealing with this next.<br /><br />It should be said that it was hard work - most of the guys were suffering with jet lag, and one had an upset stomach. It's also been a bit warmer there than we normally face this time of year, and some had difficulty sleeping at night. Despite these problems, everyone was really pleased - and I have to say that it is very clear that we have made a major leap forward.<br /><br />We still have a lot of work to do, but we are almost back on schedule to go live in a couple of moths time. If we can get the data done on time next, then it should be possible to start the next stage of testing in the test system before the end of the month - and if it there are no major problems, we will be back on track.<br /><br />It helps that there are not that many staff at that site and that they don't have to learn all of the various processes. But there is a lot more confidence now, both on site and in the project team. It has been said that it may be necessary to organise another trip over, and if we do, I'm sure that it will prove to be as valuable an exercise as this one was.Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-129857922559830319.post-67136989043654800082011-04-09T11:46:00.000-07:002011-04-09T12:46:34.920-07:00Learning the hard wayI got back late last night from our overseas site. The project lead and I made a trip over to check on how things were going, and to make arrangements for some later work.<br /><br />The first issue was the cleansing and preparation of data. When we first did this for the initial project, we found that there were some key issues - getting the actual data extracted into a format that people could use, then getting the relevant departments to tackle the job of cleaning the data out so that we would have only good stuff to load.<br /><br />We'd found that this was a lot harder than we had anticipated. Some of the data extracts from the legacy system were OK, but there were many areas where the different aspects of the data were not together in the old database, so it required some careful work and a lot of double checking in order to assemble the separate bits of data together. We made this point very clearly to the people at the new site - and gave them what we thought would be the right tools to help them.<br /><br />Unfortunately, the extract has again taken a lot longer than we expected. In this case, they are dealing with an outside company on a system that we know little about, and the actual data only started coming thru about 4-5 weeks ago. They have been checking the data, but there is still a lot to do - the first couple of tests showed that they are not even close to having it ready for the full data load process which is supposed to start in 1 weeks time.<br /><br />I'm not involved in it this time - one of my staff is doing the data load and I have virtually lost him for the next month whilst he processes the data. He is really confident and I'm sure that he will do it right - but I know from the work that he has done previously, that it will take more than just the next month to finish. He gets bored with things very easily and moves on to new stuff before finishing a job - I have to monitor him all the time and keeping reining him back in to make sure that he stays on track.<br /><br />There is another concern as well - and it relates to the knowledge transfer process. I think that the big problem here is that several of the staff are still thinking in terms of how they do the various processes within their existing system. They then have got the consultants to show them how that specific process is done in SAP - and that is not the best way to approach learning the product.<br /><br />When we first started, I read in several books that it was important to understand that implementing SAP is very different to many other products. To begin with, I probably didn't really see why that should be the case, but having spent a while working with it now, I can see that point that these people were trying to make. It's necessary to learn how to do it the "SAP way" and almost forget how things used to be done (yes, there may be exceptions).<br /><br />I'd made that point on my previous visits to the site, but I don't think that they really understood what I was trying to tell them. As a result, they are still thinking on how the process was done in the legacy sysem, and then try to remember how that process is then done with SAP. I know that it is still early days, but I don't think that there is a single person yet that can actually complete a single process on their own, even if they are using the training material that they have.<br /><br />I did speak to the project lead about this, but he doesn't seem to be too worried. His view is that they will pick up speed and they will all be ready by the time of their go-live. I'm not so sure - I don't think that they have had sufficient hands on experience with the consultants, and I'm convinced that whilst they may have seen a given process, they don't fully know any of them.<br /><br />Unfortunately, our project lead has been working with SAP now every day for several years, and I get the feeling that he expects everyone else to know as much about it as he does. Even tho he has watched them and seen just how slow and uncertain they are, he is convinced that they will improve in a very short time. For me, I am a bit concerned that they won't keep up their practisng if we are not staying on top of them.<br /><br />And that of course is going to be a big thing. We will of course provide some support for them, but it's going to be a bit difficult - certainly not as easy as when you are on a single site, or even a few hundred miles apart as long as you speak the same language. It will be much better for everyone if they are more confident in using the system before they go live.<br /><br />I've also been told that it is absolutely essential they go live no later than the last week of July. It won't be possible for them to continue working with their legacy system after then. I did think about suggesting perhaps we should consider a backup plan in case we can't get the data load, and testing finshed by then, but it was pretty clear that this would not have a been a welcome suggestion.<br /><br />I get the feeling that our project team are going to be earning a lot of frequent flyer miles!Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-129857922559830319.post-21727615795547183312011-04-03T07:00:00.000-07:002011-04-03T07:50:19.926-07:00...And yet another.When we first started creating the roles for users, I took the advice of the consultants - but after a short while, realised that it was going to get a bit more complicated than I had originally expected. For that reason, I changed the names of the roles, using Z1 for those at our first site, Z2 at the second, Z3 at the third.<br /><br />The reason for this was that we actually needed to define some limits to what people on each site would be able to do. We didn't want the staff at our second site to have the oppotunity to make changes to items from the main site. This seemed to work quite well, but then I found that some roles were getting very big - and at that point, I started to split the roles down.<br /><br />We had a hierarchy - sales clerk, sales manager and added a couple of other items to this to allow some staff more access to do certain functions. So for example, 2 staff are involved in contract review, so we have a role for that. 2 other staff are involved in dealing with certain groups of customers, and that is a seperate role as well. <br /><br />There were some issues right from the beginning, as the project team didn't really understand the concept of permissions - I would regularly be asked to give someone access to something, and when I pointed out that it was to the role that permission was granted, they would get very frustrated. However, it appears that for the most part, they now do understand and we do have a set of roles that serve our needs.<br /><br />When we started on our first overseas site, I copied the basic roles from our second site, changed the organisational levels and applied user accounts to get them started as Z4. I felt that as we had most of the authorisations already confirmed, this would be pretty much what was needed. I sent details through to the relevant people, including the consultants that I had been told would be doing the necessary work, and waited for some minor changes.<br /><br />Up until the first day of the work to go thru the processes with the staff, I had heard nothing. Later in the day, I received an email from a completely new consultant asking me to give permission for the staff member to have access to certain t-codes. When I checked, about 80% of those were already in the relevant role, and the member of staff had been added to the role. The few remaining were t-codes that we didn't actually use - we used different ones to do the same job.<br /><br />I had several more emails requesting access, each time on the day of the process testing rather that before hand. In several cases, I pointed out that the t-codes being requested were restricted to certain people. It was decided that currency rates, period closure etc would be done centrally, rather than have different people at each site getting involved. However, I was also asked to provide access to certain t-codes that I was very reluctant to hand over - why would the staff members need access to things such as SCC4, STMS, SE16N just to name a couple. These are only for administrative positions, and I could see lots of issues if they had access to these.<br /><br />What I didn't know was that the staff at our overseas site had made a complaint that they didn't feel that they were getting the relevant training they needed and this was passed to our CEO. He then discussed this with the director of the SI, who basically said that I was holding up the work by not providing the required access.<br /><br />I was dragged into the CEO's office, and to be brief, he told me that the SI were insisting that I give all of the staff at our overseas site the profile SAP_ALL. I tried to point out that this was not good practice etc. but this cut no ice. I highlighted that we needed to get the roles right, but he had been told that this could be done afterwards - in order to get the site up and running as soon as possible, they needed SAP_ALL.<br /><br />At that point, I told him that if he wanted this, I required him to put it in writing - and I thought that he was going to explode. I won't go into the discussion because it's not necessary, but it was very unpleasant. However, I did get the instruction in writing as I requested.<br /><br />Someone has subsequently said that he thinks that's a good thing - that when things go wrong, I can produce the written instruction, and throw it back at him. That's not why I did this - when it goes wrong, I will not bother arguing, I'll just get on and try to resolve the problem. My reason for asking for the instruction to be in writing, was to make sure that he understood just how seriously I take the issue.<br /><br />As it happens, the process testing over at the other site is way behind. They still have almost all of the work to go thru still, and based upon the last project plan, we are about a month behind. There is going to be a big push in a couple of weeks and I have done some work to allow some of our people to do some testing for them. However, I'm not convinced that this will be of any value, as it it appears the consultants are teaching the staff over there different processes to what our people worked on.<br /><br />I have reason to believe that the SI are pushing to get our overseas site operational on the agreed date, no matter if they are ready or not. I think that this is potentially a serious error of judgement - if they are not ready, we should admit that, and hold off until they are ready. Pushing for them to go live without them being ready could be disastrous - and not just for them, but for the company as a whole.Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-129857922559830319.post-57057728347805321862011-03-27T08:27:00.000-07:002011-03-27T09:17:41.300-07:00...and another?As anyone that works with SAP will know, it is normally set-up as a 3 system landscape. So you have one system which is for development work, one system for testing purposes and another system which is the actual production server - the one that is used by the organization for the day to day work. <br /><br />The reason behind this is really quite sensible - when you have an ERP system, it is usually really quite important that the production system continues to operate without interruption. Making changes can have pretty serious consequences - you don't want to make a change and then find that it causes the system to fall over everytime someone enters a piece of data (and most people have had experience of exactly that happening). <br /><br />So having the 3 systems allows you to do development work on one system which won't generally affect anyone else, plus you can then test out the changes on the second system to make sure that there are no undesirable side affects. Once this is fully tested, the changes can be applied to the production system and this will reduce the likelihood of the changes creating an issue that will stop the main system from running as it should. <br /><br />When we started out, the consultants did actually explain this - however, our project team members didn't really latch onto the concept. Even some considerable time later, they still didn't really fully grasp the purpose of the 3 system landscape. In fact, I would suggest that most of them thought the idea was we would start with the development system, then at some point we would move to the test system, but that that meant the development system was then no longer needed. The same would then happen to move to the production system, at which point the test system would become redundant. They just couldn't see why the others were needed once we had moved to the production system. <br /><br />Unfortunately, we have had a problem with this - the consultants from the SI and our project leader regularly perform development work in the production system. In some cases, it is just a variant to a report - but on a number of occasions, it has been a bit more than that. There are many times that I've seen our project leader working on producing a new report or even a Z t-code. I can't tell you how many times I have had an email asking me to add a new t-code to a role, only to find that it doesn't exist in the master system. <br /><br />Now I have raised this issue (more than a few times), but the problem is that every time, he will simply say that he is just following the same procedure as the people from the SI. I can't dispute that - it's exactly what they do. The fact that they shouldn't doesn't come into the argument. It's difficult to say that he shouldn't do it, when the people that we are paying a great deal of money to, ignore some of the most basic practices. And of course, if the project leader (who is a senior manager) doesn't follow the correct procedure, then it's a bit difficult to get other people to do it the way that it should be done. "Monkey see, monkey do". <br /><br />What I have found a bit irritating is that the project leader does actually understand the reason behind this, and he fully supports my attempts to get people to use the appropriate system. (However, that doesn't apply to him of course!) There was an incident about 2 months ago, and he was bouncing off the walls about the fact that someone was doing what they shouldn't - but he ignored the fact that he had been doing the same thing just a couple of days before. He just couldn't see that people will do as he does, rather than as he says they should. <br /><br />I remember reading something a few years ago - it's essential to train people up in the way that you want them to work, right from the beginning. There is no point in training people to do things one way, then try to get them to change later as it seldom works out the way that you want. I have to say, we have proven the value of that - I doubt very much that we will ever be able to get people to change their way of working now. I suspect that even if we have a major disaster, they will still carry on in exactly the same way after it has all been sorted out. <br /><br />But it doesn't mean that it's right - or that we should tolerate it. This slackness leads on to other problems - but more of that another time.<br /><br />(I've just noticed that there was an issue with the paragraphs on the original post - I've now corrected that. Sorry to anyone that was frightened off by a mass of text!)Unknownnoreply@blogger.com3