INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Where Does Agile Fit in SAP Projects?

November 12th, 2012 by
Agile on SAP projects

Agile SAP Success

After offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does work.

  • Design sessions
  • Development efforts (i.e. coding)
  • Data conversions

Once you begin to move very far beyond these areas you quickly encounter dependent work streams that need much more coordination.  Those additional dependencies make it difficult to apply Agile methods.

While Agile tends to emphasize the 1 week to 1 month “sprint,” I would define a “sprint” in more of a completed requirements and planning package rather than a pure time-box approach.

 

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

Since Agile methods have been used for some time with small, discrete components of software development I won’t spend a lot of time there.  On a typical SAP project you will end up with a functional spec which defines the program requirements and a technical spec which informs the development details.  Even though the more typical “Agile Manifesto” method would not require the documentation it is well-placed on an SAP project.  In fact, it is foolish not to have it for long term support and maintenance. 

Development can work well for the Agile stages of build / prototype, demonstrate, gather feedback, adjust, and repeat.  The key here is to limit the number of these “Agile” cycles to no more than 3 for software development.  By 3 cycles I mean 3 completed cycles too.  This is not a demonstration with feedback that is only partially built.  If the feedback cycle is not completely implemented then it is not a complete cycle.  Even though Agile would consider these “sprints,” I would consider them a FAILED sprint if the requirements of the current plan, or the subsequent plans, are not fully realized in the prototype or demonstration.

SAP Data Conversions using Agile Sprints

With data conversions I suggest at least 3 complete cycles or “sprints” (not including a minimum of 1 mock go-live conversion, probably 2 or more if you can). 

  1. Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
  2. Pilot a test conversion with all data, no matter how much fails, and capture all necessary changes.  This will include data dependencies and sequencing.  At this point you will be lucky to achieve a 70% success rate when considering all of the data dependencies.  This step is not about getting things perfect but about identifying data and programming issues to resolve.
  3. Implement all SAP data conversion changes the conversion pilot exposes, script every conversion step and rough timings, and aim for a successful test target of at least 90%.
  4. Make additional changes and attempt to follow the scripted conversion, making adjustments to the conversion script where necessary, and achieve a goal of at least 98% conversion completeness and accuracy.

Once you achieve this level of conversion consistency it is ready for a mock-conversion.  These Agile “sprints,” or as they are starting to call them now “Scrum-ban” (as a spinoff of Kanban) will help to ensure a successful data conversion.

Agile Design

Agile processes or sprints, are effective for design sessions.  Done correctly, this allows a customer to be exposed to the system earlier, provide better insights and results, and generally improve overall solution fit.  

One of the major differences with Agile Design vs. the traditional SAP Blueprint is the timeline.  An Agile Design approach requires more time because there is an element of system setup and solution discovery.  In the traditional Blueprint approach, everything is done on paper and many details are often missed.

When you combine an Agile Design approach with Lean principles, you can see overall project benefits in quality, cost, and overall solution stability at go live.  What this means is that during the design you are actually doing small “sprint” type activities to build out key areas of the solution.  Design sessions become playback and adjustment.  One key consideration with this approach is that you will not have 100% of the integration areas, or solution areas completely set up and defined.  This is important to understand.  If a customer expects to see perfection during Agile Design then a more structured waterfall approach, with a formal paper Blueprint would be required before any system solution activities are performed.

Conclusion on Agile in SAP or other ERP Projects

Even with newly packaged Scrum, Agile, or other methods, on an SAP project there are so many moving parts and work streams to coordinate that there is no substitute for a good waterfall project approach.  Using “Agile-like” methods for the ABAP development or data conversions is not a substitute for good project management either.  Done properly this approach can work well as long as it is carefully managed along with the rest of the work streams.

The Agile approach that works for an SAP deployment is one with a mix of both Agile for discrete task areas combined with a waterfall overlay.




Popular Searches:


  • erp prototype
  • what is erp prototype
  • what is prototype for erp

Related Posts:

The SAP User Experience

April 9th, 2012 by
SAP User Experience

SAP User Experience

Over a decade ago SAP embarked on a journey to revamp their outdated user interface.  Enter “nJoy” SAP with all of the new “N” transactions.  But it has been over a decade now and other than some nice refinements to the GUI not much has changed.  A decade in the technology space is like a century in other areas.  Isn’t it time to take a hard look at the application suite again?

So you have the cute “Netweaver Business Client” but there hasn’t been a lot done to change the user experience for SAP applications.

Features, Functionality, Usability, and Performance Directly Translate Into User Experience

SAP Features, Functionality, and German Engineering

Let’s look at SAP’s years of leadership in the features and functionality area of Enterprise applications:

  • No matter what any other enterprise software vendor claims they can not come close to the depth of enterprise application experience SAP has.  A recent SAP fact sheet claims more than 183,000 customers in more than 130 countries (retrieved 4/8/2012).
  • SAP supports at least 22 major industry vertical solutions [FN1] covering such diverse areas as Automotive, Banking, Chemicals, Governement (Public Sector), High Tech, Mining, Pharmaceutical, Retail, etc.  Each of these areas has its own specialized process nuances and the application additions require specialized support.

The SAP application suite is massive as well.  If you’ve ever looked at an SAP price list you’ve probably been thoroughly confused and overwhelmed.  The SAP enterprise application footprint is gigantic.  SAP R&D spend for 2011 was about 13.5% of gross revenue (or about 1.9B Euros) and with a few exceptions SAP R&D spend is generally in the double-digit area of gross revenue.  Think about that, 1.9B Euros in R&D spend is more than the gross revenue of most of their competitors enterprise application sales.

Consider the depth and breadth of application functionality in the context of the various solution options available (see Footnote 2 below for a SMALL sample from ONE Application Component area) [FN2].  If you’ve ever had to deal with an SAP price-list trying to develop enterprise solution architecture, or license requirements, you may quickly become overwhelmed by the massive feature and functionality landscape. 

SAP Performance Options

Many of SAP’s products are hardware and database agnostic.  I don’t mean that it will run on any hardware, or any database, but it will run on most major platforms.  Because of the way the applications are structured they will also run in what SAP callls “2 tier” or “3 tier” landscapes.  This means the applications are scalable, in both size and performance, to whatever level of hardware investment you decide.

With the introduction of SAP’s HANA in memory computing solution(s), performance within the application is changing by orders of magnitude.  Massive amounts of data and programs are now loaded into, and then read from memory rather than from hard drives.

Whether you want to scale up or use HANA system performance should never be an issue.

Usability, Usability on the Wall, Who’s the Fairest of Them All?

Now we get to the heart of the matter.  As demonstrated SAP is a GREAT engineering company with huge R&D spend, a comprehensive industry solution portfolio, and a mountain of enterprise application options.  They’re German, what did you expect? Scalability and performance are not issues so the only area left is usability.

The “nJoy” program is about a decade and a half old.  In technology terms that is like the difference between the Stone Age and the industrial Revolution.

Unfortunately on the user experience curve they are in the IT Stone Age.  While there are great functionality enhancements coming out in the various enhancement packs at the same time the ability to use the application suffers.  Each major version of the SAP GUI offers a more pleasing screen, but it is still the same underlying data entry requirement–, the same fields, the same tabs, the same screens, the same old everything with a little bit of “lipstick” added.  But it is still the same fat, bloated, over-engineered user experience. 

SAP User Experience Customizing Pain

Please, don’t tell me about GUI XT or any of the other “customizing” options for screen layouts.  The starting point stinks and then you expect a customer to pay (consulting time, employee time, system integrator time, etc.) to enhance or modify the screens.  The SAP enhancement or modification option is not simple either — a simple screen enhancement is a significant engineering undertaking.  Unlike several modern “drag and drop” applications SAP requires development work to add new fields, change field labels, populate data in those fields during transaction run time, screen development is needed to “build” a new screen layout, and then you have to reassign a new “Z” transaction with copies of the modified underlying programs, adjust security, etc.  It takes a major engineering effort to make SMALL changes to the user experience.  SAP you have GOT to change this!  Your customers should be able to focus on the user interface without having to worry about all of the underlying engineering.

A Model for the SAP User Experience

Recently I offered The PERFECT SAP Acquisition Target in a CRM application called “SugarCRM.” As an SAP consultant who wants to see SAP continue to do well there are a lot of lessons that can be learned from them.  They are a cloud vendor who has set their target on Salesforce.com.  They provide a great navigation and ease of use experience.  And best of all, you can alter field labels, hide fields, add custom fields, completely change the layout of screens, and a whole host of other things without having to do any coding at all. Even if this isn’t an acquisition possibility for SAP it might help some of those German engineers in the SAP CRM space to download the opensource version and explore it.  Maybe they will learn a little something from a scrappy upstart who recently received $46 million in venture capital.  And this was from several VC organizations so a number of investors are betting millions on SugarCRM’s marketplace viability–, even in a marketplace saturated by salesforce.com and Microsoft.

Apple has Proven that User Experience Can MAKE the Market by Addressing Customer Pain Points

It’s been a long time SAP since you have seriously considered a remake of the user experience.  Since then Apple has proven that addressing customer “pain points” is a market winner. It’s about time to take another hard look at the user interface and user interactions because SAP “usability” has always been a customer pain point.  The “nJoy” program is about a decade and a half old.  In technology terms that is like the difference between the Stone Age and the industrial Revolution.  Don’t you think it’s time to get really serious about the user experience paradigm?

==============

[FN1] Retrieved 4/8/2012 from http://help.sap.com/industries.  Along with this there are “sub” solutions within several of the industries and across industries.

[FN2]

SAP Application Components

like SAP Auto-ID Infrastructure, SAP BOBJ Spend Performance Mgmt, SAP CRM, SAP ERP, SAP SCM, SAP SNC, SAP SRM, …

SAP Best Practices

SAP Best Practices packages are available in different country versions for various industries

SAP BusinessObjects portfolio

like Address Directories & Reference Data, Crystal Reports Viewer, SBOP Data Federator, SBOP Enterprise, SBOP Extended Analytics, SBOP Text Analysis, …

SAP Business One

like SAP Business One 8.8, SAP Business One 2007, Crystal Reports for B1, Remote Support Platform for B1, …

SAP Connectors

like Business Connector, …

SAP Content

like BI CONT, SAP Business ByDesign CONTENT, …

SAP Cryptographic Software

like SAP Cryptographic Library, …

SAP Development Projects

like customer-specific development projects software, …

SAP Education Products

like Acrobat Con Learning by Adobe, Knowledge Acceleration, RWD Info Pak Suite, SAP Productivity Pak by RWD, SAP UEM by KNOA, Training Content for SAP KW, …

SAP Frontend Components

like NetWeaver Business Client, SAP GUI for Windows, SAP GUI for JAVA, SAP ITS, SAP IGS, …

SAP In-Memory (SAP HANA)

like SAP HANA Enterprise Edition, SAP HANA Enterprise Ext. Edit., SAP HANA Platform Edition

SAP Mobile Solutions

like MOB ACCAPROVER INT, MOB HR APPROVAL INT, MOB MGR INSIGHT IPD, …

SAP NetWeaver and complementary products

like SAP NetWeaver, SAP NetWeaver CE, SAP NetWeaver Mobile, SAP NW Identity Management, SAP MDM, SAP Content Server, …

SAP On-Demand Solutions

like SAP Sales OD Integration

SAP Rapid Deployment solutions

like SAP Business Communication Management rapid-deployment solution, SAP CRM rapid-deployment solution for Sales, Marketing, and Service, SAP IT Service Desk Operation rapid-deployment solution, …

SAP Solution Extensions by Partners

like BOBJ XBRL Publishing UBMatrix, SAP CPS Full (Scheduler), SAP Ext. Diagn. by CA Wily, SAP IncentivePayback by Vistex, SAP Quality Center by HP, …

SAP Solutions for Governance, Risk, and Compliance

like SAP Global Trade Services, SAP GRC Access Control, SAP Process Control, SAP Risk Management, SAP Nota Fiscal Electronica, …

SAP Technology Components

like LV for Solution Manager, Remote Support Component, SAP Landscape Transformation, SAP Solution Manager, SAP Support Enablement Package, SAP TAO, …

Adapters

like Informatica, IWay, Seeburger, for SAP NetWeaver 04 (EP Edition), for SAP XI 2.0, …

Composite Applications

like Industry Composites Applications (SAP COMP App for BOP, for E-Tax) SAP DOCB, SAP CQM, SAP XIEP, SAP XLPO, SAP SOP, …

Country-specific Add-Ons

like HR-CIS, SAP Core CEE, SAP E-Recruiting – LOCFR, SAP HR-CEE, SAP IS-U/LOCIN, SAP IS-UT CEE, SAP Real Estate CEE, …

Fuzzy! Products

like Fuzzy! Analyzer, Fuzzy! Bank, Fuzzy!Boykottcheck, Fuzzy! Double, Fuzzy! Post, Fuzzy! Umzug, …

Industry-specific Components

like Banking Services from SAP, SAP Bank Analyzer, SAP CFM, SAP Deposits Management, SAP Discrete Industries, SAP Insurance, SAP IS-U, SAP Mill Products, SAP Oil & Gas, SAP Patient Management, SAP Retail, SAP Trade Industry Demand Mgmt, …

Miscellaneous Components

like AppServer LINUXx86 64 on 6.40, Convergence Tool, SAP Kernel, …

Plug-Ins

like SAP Plug-In, SAP Enterprise Portal Plug-In, SAP Solution Tools, …

Supplementary Components for Cross Industry Solutions

like Project Management, Life-Cycle Data Management (SAP PLM Integrations), SAP Railcar Management, SAP Test Data Migration Server, SAP Visual Basis, …

Sybase Products

like AFARIA, Sybase Mobile Sales, Sybase Mobile Workflow, Sybase Unwired Platform, …




Popular Searches:


  • saxi fat goals
  • what are the various painpoint sap grc tends to solve

Related Posts:

More SAP Project Leadership Tips for Managing Conflict

November 28th, 2011 by
Managing SAP Project Momentum, Stress, and Conflict

Managing SAP Project Conflict

If you are determined to gain and then maintain SAP project momentum you will see stress.  Part of the requirement for momentum includes asking people to reach for stretch goals which can challenge (and deepen) their capabilities but also causes tension and even conflict.

One author says conflict is “a situation of competition in which the parties are aware of the incompatibility of potential future positions and in which each party wishes to occupy a position which is incompatible with the wishes of the other.” [FN1] 

In plain English, conflict happens when there are competing expectations and priorities.  Put another way, I want what I want and you want what you want and the level of our conflict depends on just how much each of us wants “it”.

Without hands on, active SAP project management it is likely that stress and conflict will destroy your SAP project momentum.  Active SAP project management is not about micromanaging people or their activities but rather finding the right balance around task execution and delivery while working through the stress that will arise.  As a project manager part of your key responsibility is to work through conflict to maintain momentum.  At its most basic project SAP project management is like babysitting adults who at times act like squabbling children (and I’ve been guilty of childish squabbling as well at times!).

Key Phases of SAP Project Stress Which Can Create Conflict

In relation to physical and life stress Canadian Physician Hans Selye (1907 – 1982) proposed 3 stages of stress in his 1956 book “The Stress of Life”: 

  • Alarm
  • Resistance
  • Exhaustion

On an SAP project the alarm or panic stage occurs when you attempt to create a rapid project delivery pace.  The resistance stage occurs when the alarm does not slow down or stop the momentum that is gaining. Exhaustion or “checking out” can occur when the stresses and pressures of an overly aggressive timeline continue beyond what the project participants are able or willing to deliver.  A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

The key to good SAP project management is to maintain a sense of urgency that is strong enough to keep momentum high but no so urgent or so stressful that it causes people to burn out or check out.

There is a healthy level of tension which is needed to keep momentum going but knowing where that line is requires a project manager to be directly engaged with the project participants.  Even though it is critical to gain and then maintain momentum at times you also have to know when to ease up to allow the stress level to moderate. 

It is equally important for a project manager to know whether the alarm and resistance are from unskilled project participants who are trying to hide their lack of experience, or from unrealistic demands, or from the project as a whole. 

At First Most People Try to Deal With SAP Project Stress in a Productive Manner

Regardless of the reason for the stress, and ultimately what the conflict is, most people do attempt to mitigate the initial source of the stress.  The research shows they may:

  1. apply extra effort to compensate for the greater demands,
  2. they may attempt to overcome the stress by fixating on the task(s) which create the stress, or,
  3. they may become anxious, worry, and then avoid the tasks.

If a project manager is skilled and recognizes these signs they can quickly intervene and help to alleviate the source of the stress.  Although it is critical for momentum to keep a forward looking perspective throughout the project there are times it is more productive to pause, reflect, and allow stress levels to lower.  When you see tension and stress building to an unhealthy level it may be time for a special recognition of how much progress has been gained to help people regain a sense of perspective and give them a chance to “take a breath.”

A good SAP project manager must carefully evaluate and then manage the source(s) of alarm and resistance.

Knowing when to back off the gas and recognize accomplishments and when to press the gas and push ahead is the most difficult skill for any project manager to develop.  It is like a professional race car driver who must know when to step on the gas, when to let off, when to apply the brakes, and when to step back on the throttle.  A project manager who is able to perform that balancing act demonstrates their experience and their people skills.  This requires direct engagement with the project participants on a day to day basis. 

This type of engagement by the SAP project manager needs to be in the project participants’ work environments, not just in planned meetings where people may not be as candid or forthright.  That direct engagement requires the project manager to serve as an active umpire, counselor, decision-maker, expediter, and all around gopher to help coordinate many of the integration activities. 

A Good SAP project manager GENUINELY UNDERSTANDS that their success depends on every other project participant’s success and will directly engage in activities which help promote the success of project participants.  Sometimes this means giving some project participants the opportunity to be successful on a different project  :)

As a final thought, an SAP project manager who needs a separate “integration manager” should be more carefully considered.  It may be necessary but do you really need a Microsoft Project administrator or a meeting monitor or do you need a manager for your project?  Needing an “integraton manager” may be a way to avoid the day to day involvement that is critical for SAP project success.

============

[FN1]  Capozzoli TK. Conflict resolution-a key ingredient in successful teams. Supervision (60:11), 1999, pp 14-16

Related Posts: