It has been a bit more than 5 years that SAP Transportation Management now has been in General Availability status in the marketplace. Starting with SAP TM 8.0, for what seemed like a very long time we worked in a visionary stage of a software life cycle.
Today, critical mass on many levels has been achieved - functional coverage, customer adoption, successes in many industries and geographies, software analyst recognition. Some other areas still lack that necessary critical mass. I plan to talk about some of these areas in upcoming blogs.
The paradigm has clearly shifted - which is good news for anyone involved with SAP TM. The tone of the discussion has moved on from a theoretical 'is SAP TM stable, what can it do, is it for real, is it ready for primetime?' to a much more practical 'how do/should we implement, what does it take, help me find the benefits.'
With SAP TM 9.3 we have now entered the practitioners phase of a software life cycle.
While convincing and selling software to a client is hard enough, we all know that the real hard work will only begin when the implementation project commences. So how do you ensure success when you are finally ready to go? How do you line up the proverbial 'ducks in a row' to ensure that they all waddle in the right direction?
How do you become a STAR with SAP Transportation Management? Scope, Talent, Approach, Realism - S.T.A.R. - can be used to structure your thinking.
So let’s use the S.T.A.R. acronym to help us structure our effort with SAP Transportation Management. In future posts we will dive deeper into each one of these areas.
Companies have become very good nowadays to make investment decisions based on sound Business Cases. However, a Business Case does not necessarily translate 1:1 into project scope. SAP TM has a feature and scenario rich software package - Order Management, Planning & Scheduling, Execution & Dispatching, Carrier Management, Invoicing & Settlement, Track & Trace, Strategic Freight Management & Procurement represent only the highest level of functional coverage.
Furthermore, SAP TM project typically have a geographical scope as well. A country or facility being implemented first before others follow. Sometime a business unit is the pilot within a company leading the way.
Ensuring success however means that you need to find that ever so important sweet spot allowing you to have some early success. Too many projects suffer from scope creep or project delays and cost overruns because the scope was too aggressive, too ambitious. Oftentimes while the scope might be initially logical, the scope does not line up with the next few success criteria. It results in scope imbalance.
Project staffing is obviously a fundamental step of project preparation. Good or even great SAP TM consultants, functional or technical, are still in high demand. Nobody can expect to just raise a finger and expect to find the right resources for the job. At Novigo we have been very successful matching some very senior people with young TM talent, allowing us to provide a balanced resource mix to our clients and also being fair on the budget side of things.
Novigo over the last 6 years invested significant resources into its own SAP TM Academy, resulting in young TM consultants to be certified in SAP software modules like TM, but also other elementary consulting skills like PMP project management.
While external resources provide the fuel to drive a project, the engine has to be staffed by internal resources. Subject Matter Experts, Project Management resources, Change Agents, Basis and Technical Resources are only highlighting the need to have skilled internal people participate, some of the full-time, others part-time.
Customers should be accountable. Customers need to guarantee quick decision making. Customers need to be invested.
All of the above will be easier - not easy - with an Executive Stakeholder providing the right amount of leadership, motivation and backing in case of critical times.
This is certainly about Project Methodology - many books and articles have been written about this topic. Still, I continue to be surprised how many larger software projects fail to deliver upon the promises or expectations that had been created early on.
TM is very powerful, flexible - sometimes overly flexible to its own un-doing - however it needs to be treated carefully. Don’t expect TM to just jump off the shelf and magically configure itself. Novigo has taken an approach where we have become extremely prototypical in the early stages of a project, call it blueprint or design phase. The whole idea is to avoid over-use of paper and excel sheets and create false expectations. Quite in contrast getting SME’s and potentially some key users on-board is very comforting to the overall state of the attitude in the project.
Don’t get this wrong, documentation is important and it will be written, however at the right point in time. 'Seeing is believing’ will create proponents and it will prepare everyone for change. And change will come, the question is how radical and sudden this change has to be.
In essence such an approach takes elements of the Agile Methodology and just applies it in reality. The approach builds prototype after prototype and we all know that prototypes are very rarely also the finished product. The difference is that most everyone loves to touch and feel a product before its inception.
Ask us how we make this approach work, it for sure gives us at Novigo an enormous amount of confidence going into a project. More details on this at a later point in time.
Another aspect of approach is to make User-Friendliness and Reporting a priority from Day 1. Don't shy away from making the solution pretty, from thinking about the End-Game. Have at least a Dashboard View available in Mock-Up that the project team should thrive for. Any Project Charter will clearly articulate certain KPI's that will later judge the success of a project, even if those KPI's will only become measurable in Phase 2 or 3 of a project. These KPI's are the proverbial 'Hangers' that the project team can hang their hats on. Keep circling back to these goals throughout the project to quantify progress.
This aspect is probably the most controversial. Setting the right scope certainly can be classified as being 'real'. I would like to discuss a different aspect of realism, and this is realism starts during the software sales cycle. Every software manufacturer - regardless of on-premise, cloud, SaaS technology - will over-sell. It is human nature to over simplify complex situations when pressed for explanations.
And this is what this aspect is about. Most software sales cycles stay on the surface. RFP's ask hundreds if not thousands of question towards capabilities of the software, they will ask for customer references, ask for effort estimates and hi-level budgets.
Realistic project planning will always allow for a contingency, however it will not necessarily tell everyone that these contingencies are in place, otherwise the effort will slack.
It is understandable that some software projects need to be significant in its transformational aspirations. At the same time, give the project team a chance to succeed by scheduling that first go-live. Identify the 'low-hanging fruit' - the fruit is there, believe me, even in the world of SAP Transportation Management' or any other TMS solution.
Allow Novigo to help you in bringing this realism into your project planning phase, Preparation is Everything.
The purpose of this blog is to remind of some basic principles. A decision for SAP TM is one for the future of a company. The effort might seem insurmountable, the best way to solve this problem is to break it down into smaller elements.
S.T.A.R. gives you an opportunity to start in a more structured manner. Allow Executives to have the vision, on project level the task at hand is to translate this vision into a pragmatic and realistic approach. If you gather the right talent, you are already halfway to the finish line.