Technology Negotiations are Still Hard

Technology negotiations are different from other business deals and this has not changed much in spite of the increased digital literacy of our business colleagues.  As Lawrence Susskind wrote in a 2006 Harvard Business Review article, four problems routinely crop up in digital technology negotiations that are not as likely to arise in negotiations that are less digitally complex: 

  • The complexity of the other systems that the negotiated product must fit.
  • The uncertainty of how the product will perform in a particular business environment.
  • The egos of the system advocates who feel they have a vested interest in the outcomes.
  • The organizational change involved for the various affected departments.

And one more, based on my experience as a CIO and project manager for many years:

  • The difficulty acquiring intelligence on what is the right price. Software vendors generally give deep discounts; sometimes approaching 95% of list and without deep digital technology relationships you may leave some on the table.

Consider that as a digital technology leader you possess the knowledge needed to navigate the complexities of the digital landscape.  Also consider that if you have earned the trust needed to be an advisor, you can fill the role of consiglieri to the technology advocates before during and after the negotiations to mitigate the uncertainty, ego and organizational change complications and get what is best for the organization.

Crossroads of Control vs. Digital cont.

In my last post, Crossroads of Control vs. Digital, I said would discuss the next logical questions for an IT leader.  The first of which is “How do you embrace this “new world order” without having everyone in the business do their own thing, with little consideration for overall company mission & best practices?”   News Flash: Folks are doing their own thing already.  Embrace it and become an enabler, nay, a leader of a bottom-up, federated technology department focused not on control but on driving productivity and value.

To be successful this will begin at home with what is the biggest impediment – your team.  Your team is accustomed to having control.  You will need to educate them on the new ways and integrate them back into the business.  This means three things.

  • Solid multi-layer governance led not by IT but by the departments in your business.
  • A keen focus on enterprise architecture not to be confused with technical architecture.
  • And perhaps most importantly, immersion of the technologists at the individual level into the various business departments in a way that is a conduit for understanding and influence.

You may feel you are giving up the control, but that perceived control comes with sub-optimal productivity, sub-optimal meeting of customer demand, sub-optimal profits or surpluses and sub-optimal sustainability.  The reward of improved productivity, improved morale, meeting customer demands and bottom line improvements will be worth the short term discomfort.

 

Crossroads of Control vs Power

“The technology for digital business is stateless and loosely-coupled, not stateful and closely-coupled like IT.”  This quote from Andy Mulholland, VP & Principal Analyst at Constellation Research, caught my attention because it captures a paradigm shift that most IT leaders struggle to embrace.  

There is a sense of security in the technology control processes that IT created due to a lack of digital literacy within businesses in the past.  Today, however, digital literacy is universal within not only businesses, but society at large.  The challenge to IT leaders today?  Embrace the stateless and loosely-coupled nature of digital business by creating the required relationship networks.  The reward will be a new sense of power that not only improves their ability to deliver on their mission, but will result in better job satisfaction for their teams.

In my next post, I will discuss the next logical questions for an IT leader:

  • How do you embrace this “new world order” without having everyone in the business do their own thing, with little consideration for overall company mission & best practices? 
  • And how do you prevent the business from getting abused and taken advantage of by the technology vendors that love nothing more than having business “go around IT” and work directly with them?

Business teams definitely know more about technology than they did 20 years ago, but do they know enough to make solid decisions about complex technology on their own?  Now, more than ever, is the time for IT leaders to show a healthy respect for business leaders’ interests while positioning themselves as trusted advisors and experts.

Well Done, Woodgrain!

We enjoyed reading about Woodgrain's continued success with the Transportation Management solution we helped them implement and how that solution is helping them manage their current growth spurt!

SAP News Article - Woodgrain Millwork: Delivering the Poetry of Architecture by the Truckload

You can watch videos about their use of TM as well:

   Connie Moylan, CIO, gives a great overview of how Woodgrain uses TM

   Tyler Roorda & our very own Anton Karnaukhov presented at SAPPHIRE on how TM was implemented and their lessons learned.

 

 

SAP Transportation Management - Frequently Asked Questions (FAQ)

We decided to compile and share a list of question about SAP Transportation Management (TM) that we hear most frequently from companies that are interested in learning more about SAP TM.  A lot of these questions are fairly basic and high-level, so this FAQ will be most helpful to people who have limited knowledge of SAP Transportation Management capabilities and requirements.

BRFplus - a hidden gem within your SAP system

No matter how much one tries to minimize customization in an SAP system some volume of custom business logic is usually unavoidable.  Historically this meant introducing custom ABAP syntax in various user-exists, enhancements, BAdI's and custom programs.  Given the complex and interdependent nature of an SAP system, it becomes imperative to carefully manage such ABAP-based customization in order to ensure that business logic is in sync across various functional areas and is not duplicated.  That's where SAP Business Rules Framework Plus (BRFplus) comes into play - a fairly new piece of functionality from SAP that makes it possible to manage all of your custom business logic in a single place and in a re-usable way.

Why CIOs Get (Deserve?) A Bad Rep

In the last few weeks, I’ve seen several articles about the challenges with and for CIOs: How CIOs are the obstacle to the missions of business executives; how CIOs and CMOs need to learn to work together; and even articles asking ‘Whose business is IT?’.  Examples include these posts by Michael Krigsman: “CIO and IT Leaders: YOU hold the burden of proof”, and “McKinsey research: IT needs a kick in the keister”.

Sadly, this is not a new discussion...

Test Driving SAP Transportation Management Optimization

One of the requests we often get at BestXperts from companies interested in learning more about SAP Transportation Management is whether they can provide us with some sample order data and have us run it through SAP TM optimization.  This is especially relevant for companies that operate their own fleet of vehicles and are interested in optimizing routes, looking for back haul opportunities as well as optimal stop sequencing in case of multi-stop shipments.

Baby, You Can Drive My Car (SAPPHIRE News from BestXperts)

You know that Beatles' song, Drive My Car?

Sure, on the surface it's about one person's dream of fame - but at heart it's about taking risks.

You can go ahead and hit the road with your vision - and maybe a driver - but you don't have to get bogged down by planning every step before you even start.

Explore the theme of getting started, paired with some reasonable risk-taking, by joining two SAPPHIRE presentations by Anton Karnaukhov and our client, Woodgrain Millworks.

A dinner chat with Mike Vizdos

I've been following Mike Vizdos @mvizdos on Twitter for quite some time now.  His popular web site implementingscrum.com mixes a healthy dose of cartoon humor with some very practical and handy advice on utilizing Scrum.  So when Mike tweeted about being in Sacramento for the week we reached out and asked if he would be interested in exchanging ideas over some food and a couple of brews.  Thankfully, Mike was gracious enough to accept our offer.

We ended up discussing some engaging topics and ideas, many of which left me thinking and reflecting on for many days to come.  But there were a few discussion points that left an especially long-lasting impression.

Feature planning in an agile SAP implementation

In one of our previous posts we talked about the core roles and basic team structure in an agile SAP implementation.  We are now ready to take a look at one of the first steps in planning the implementation and assessing the work that will need to be done by each team - defining the project features. 

A feature (aka epic or epic story) is the next level down from the overall project in that a single project contains one or more features. There is no black and white rule on what makes up a feature but here are some guiding principles that we try to utilize:

SAP Transportation Management 9: Early to the Party!

The BestXperts team appreciated the challenge from Woodgrain Millwork to not only guide them through a full rework of their Distribution processes and systems but to make the very new SAP Transportation Management (TM) 9 the hub of that solution. After months of site visits, planning and design sessions, coaching of the Woodgrain IT team and, of course, lots of configuration and development work, the new solutions had a successful go-live on June 3, 2013!

Agile Terminology for SAP Project Teams

We don't need to tell anyone who is used to working with SAP that getting the terminology right is often a daunting task.  Agile project management brings with it a number of new terms that are critical to understand in order to be able to comprehend any of the detailed discussions on how agile can help you implement SAP solutions in a better way. These terms are by no means universal, but at BestXperts we do try to use the terminology that is most common in the agile circles, regardless if we are talking about SAP implementation projects or building a web application.

Team Structure in Agile SAP Implementation Projects

One of the first things that each software implementation project has to worry about is the general structure of the project team.  We at BestXperts have tried a few different variations of project team composition over the years and can definitely attest to the fact that there is no canned project team setup that will work on every project.

Constriction to Force Ourselves to Create

As I was reading Mike Cohn's "Agile Estimating and Planning" for the last couple of days, I've taken some notes that I thought were worth sharing and discussing.  The later sections of the book really focus on the technical aspects of agile planning, such as using points for estimation, planning poker, release planning, etc, all of which I was already fairly familiar with.  For me, most of the interesting observations were in the first half of Mike's book where estimating and planning is discussed in broader terms and contrasted with counter-part approaches in waterfall project management.

Things you SHOULDN'T do in an agile SAP implementation

It's one thing to have the desire to implement SAP software in an agile way, envisioning the benefits of significantly lower cost and much happier end-users.  It is a whole other thing to actually make it happen, resisting the constant desire to fall back to the old waterfall ways of doing things.  And have no doubt, that desire will be there for quite some time, like a juicy carrot on a stick - if only we could map the entire project in a Gantt chart, if only we could put a deadline on every task no matter how far out that task is, if only we could achieve precise estimates on anything and everything and compare them to actual time spent, then and only then we can take control of the project, determine exact go-live date and keep our executive management properly informed.  Falling into this type of thinking in an agile project is very simple.  Having the understanding, discipline and commitment to the core principles of agile throughout the entire project is often very difficult.

US needs to produce more native SAP professionals

To most people the term "SAP" is nothing more than a cryptic abbreviation.  It is far from a household name.  Few are aware of the fact that SAP is the largest business software company in the world.  Even fewer know that roughly 65% of the world's business transactions run through an SAP system at one point or another.  In many ways, SAP software runs the business world.  And every year it runs more of it. On top of this, SAP software implementations are no longer reserved for billion dollar companies with deep pockets.  We at BestXperts have a number of customers with roughly $100 million in annual revenue that have successfully implemented SAP and are able to run their business in a sustainable and flexible way.  And once a company implements SAP it typically goes on a long-term cycle of optimization, streamlining and automation of business processes through the enhancement and use of additional functionality from SAP.

Do Tools Matter?

In a meeting last week, we got into a debate about the value of tools in an organization. Specifically, we were discussing the merits of our chosen IT demand management software and Agile Project Management tool and whether or not they can be credited with the increase in productivity that our group has achieved over the past few months. During this debate, the following statement was blurted out:

Tools don't matter.

Running SAP projects - the path from waterfall to agile

We at BestXperts did not adopt agile project management overnight. In fact, it took us years to come up with an approach that was both repeatable and scalable. At first we dispensed with the idea of massive upfront blueprinting and instead began to have many mini-cycles of blueprinting, realization and testing throughout the project. In the process, we started structuring our project schedules around “sprints” and conducting daily standups to facilitate active communication within project teams.

ERP for the modern age

Don't get me wrong, we at BestXperts are diehard SAP fans. After all, we earn our living by implementing SAP software. But there are times when we just can't stop ranting about SAP idiosyncrasies that drive us crazy. Most of these rants boil down to one common trend - SAP is unnecessarily difficult. Some of this stems from the fact that SAP has turned into a behemoth with a number of large acquisitions in the last 5 years which seems to have impacted SAP's ability to execute quickly and with acceptable level of quality. Other times we get really frustrated with SAP's "enterprisy" approach to such things as mobility and web services which feel very bloated when compared with the modern technologies and approaches used in those areas in the consumer space.

So we decided to do what we do best - dream a little. What would an ERP system look like if it was built today, in 2012, making use of the current trends and technological advancements in the software development space?