A quick Google of that phrase "requirements that work" comes back with almost 10,000 hits of indexed web pages and RTW as I shall refer to them are a focus of the company, Pragmatic Marketing's training program for which you will find many links in that search. Some of their recommended reading includes great titles like "The design of everyday things" by Donald Norman and "The Inmates are running the asylum" by Alan Cooper both of which I highly recommend, these books like many others, help us to understand how successful ventures are founded largely on intelligent understanding of the market's requirements. While the requirements gathering approach from a ‘product' perspective is interesting for product managers, most important to consultants, IT personnel and the business, in my mind, is the whole idea of understanding what a given customer needs or wants for a defined problem for which you are trying to implement a defined solution . This ‘understanding' part seems to have been clearly missed with the specific SAP customer I was talking to. No fault of SAP, after all there are others in this industry segment for whom the solution is a perfect fit and again possibly no fault of the systems integrator because they delivered what they said they would and of course no fault of the customer. Well at least, that's what they told me! So where did the whole thing fall apart? A very simple requirement like being able to nuance your SAP configuration according to your specific business differentiators is probably one of the reasons why your company bought SAP in the first place; and being told that you bought a generic implementation of SAP is not likely to leave your C level executives feeling very happy especially if all the back office support staff are beating down their doors complaining that they can't use the system the way it has been provided. While SAP implementation doesn't require enhancement or customization to be implemented successfully, invariably business has to toy with the options of either reengineering the business process or changing the application. If the changes are not too onerous or not fundamentally at odds with the ‘standard' SAP processes then the configuration is appropriately tweaked, the additional fields added or the reports developed. This is not an unusual scenario; you will only know whether this needs to be done if you question, record and reflect as part of your requirements gathering.
T-shirt anyone?
Preconfigured or accelerated implementations almost always present problems around expectations management. I think of it as being a little like buying a pair of pants off the hanger without trying them on and deciding to get them adjusted when the waist hangs around your knees or the hems land up under your heels. I always seem to buy pants that are either too long or too short or too tight or too large so I know what I am talking about here! Clothing manufacturers would have us believe that we all fit into some sort of ‘standard size'; along with that other measure of things in the software development world - t shirt sizing; comes to mind here too; we all know for sure that the one size fits all story is a fallacy so, not content with the old standards of SM&L we now have a plethora of other sizes MS, ML, C, XS P, XL, XXL, XXXL etc. to cope with a more diverse community, T shirt sizing for software development is still pretty much stuck in the SML category I think. Fortunately generic implementations of SAP don't seem to be quite so clearly T shirt sized....yet. Unsurprisingly, just as people don't tuck well into these standard sizes, neither do many companies shoehorn particularly well into generic configuration. Again, the best way to remediate these types of issues before you have spent pots of money is to get your requirements down clearly and articulated early in the discussions and negotiations process.
Irrespective of whether you are following the AcceleratedSAP (ASAP) Methodology and Business Add-Ons methodology or implementing using some SI's hybridized approach to implementing SAP, the cornerstone of good configuration is a well elaborated blueprint. Here, SAP solution manager (SOLMAN) has received a bloodied nose from SI's, consultants and customers alike over the years and even recently was described as being a confusing component, but to my mind; especially if you are planning a relatively generic implementation of SAP, I cannot understand why you would NOT consider using it to help with defining your system configuration as a project. Solution Manager won't be a silver bullet to fix poor consultants, neutralize maverick business owners, resolve poor budgeting or remediate improper project management but it can be a helpful technical tool, not only for prototyping, blueprinting and realization but also for test management, service requests, change management, system monitoring and ultimately business process management and root cause analysis, it is a starting point and if you use it intelligently you can attached your final configuration rationale to the configuration objects directly in the solution manager project. When you are paying SAP large amounts of money in maintenance fees every year you are needlessly ignoring an essentially free component in your system landscape. SOLMAN sounds like a one size fit all solution, but it actually functions in a pretty clearly defined space in your system landscape and has a relatively easily understood role so there should be no real fears there, just plenty of work.
Using Solution Manager to best effect
Accordingly, when you are defining those requirements for the consultants to interpret in SAP-speak, understanding and prescribing that SOLMAN should be part of your defined system requirements will likely alleviate some pain later in the project lifecycle. This approach is far better than having requirements documents trapped in shared drives, on the harddrives of consultant laptops and chocking mail server storage. If you're new to the SAP world and SAP projects in particular then the Enterprise Modelling - Consultant's Handbook is a great start for understanding some of the things you need to consider when developing your "block of wood" for the business to ultimately use. While the content of the consultant's handbook is a little aged (dates back to 4.6c), the fundamentals still remain relevant and are worth a skim. OK, so having ERP and especially SAP on your resume will be great for your career into the future. Everyone will likely tell you that, however the accolades will only flow if your project is an overwhelming success and the business lauds your great choice of configuration and the final solution. Through appropriate diligence in your requirements gathering and using a sound analysis and implementation methodology like ASAP and tools like SOLMAN you can work towards ensuring that your final solution aligns well with your defined requirements and meets the needs of the business.
Requirements for implementation and sustainment
Consider this also when you develop your master data management strategy and your cutover planning, as well as your operations management or sustainment approach to mass change and creation of data. Relying on text files, LSMW and BDC sessions may not be the smartest or cheapest way to perform mass change and creation of data in your SAP system and the business may not find the idea of working with text files, when they like to use EXCEL, palatable at all. SAP Ecohub members like Winshuttle offer great integration solutions that don't compromise on system security and concurrently support the business in continuing to function with the tools that they use today, which may be an ongoing requirement, especially if custom integration solutions are unbudgeted or out-of-scope for the generic implementation.
Returning to this new mobile phone recently put on offer, the factors that decide whether you will upgrade, cross-grade or ignore this new telephonic gizmo are very similar to those that you may consider with respect to your SAP implementation. Up front of course is your budget, both your initial capital investment and maintenance/running costs. Next you will want to consider how easy it is to use and adopt - think usability. Old school party-line phone exchanges were less than intuitive to those that were not familiar with them; you'd need to know how many rings signified a call for you specifically; the subsequent implementation of uniquely identifiable circuits and the ability to use a rotary dialer were a boon for those who wanted self service and push button technology meant that even the ogres amongst us, could punch out a 7 digit phone number without too much difficulty. Your new resistive touch screen and lentil sized buttons however may prove to be a challenge to work with, for both grandma and the ogre but at least you will have something cool and skinny in your pocket, which again may be one of your requirements. For me, it is about being able to foursquare, tweet, FB, email, text, take photos, look up and edit contacts numbers and addresses, geo-locate myself and create calendar alarms that I can hear - all while closely integrating with my email providers and office mail server; I think it will do all of those things but the specifics I am not sure about, it's a Smartphone, it must have all these features...I hope. For grandma and the ogre I think I will keep them away from this newfangled technology after all, all that grandma wants to be able to do is easily pick programmed speed dials to call people that are important to her. A generic mobile with big buttons will do for her and probably the ogre too. I think I got the requirements - is that right?
