Feeds:
Posts
Comments

Posts Tagged ‘ERP’

Our headline is a tad misleading because, while the specifics concern Microsoft Dynamics NAV, one of the world’s leading ERP and business management software systems, the principles of the article could be applied to virtually any software system implementation.  This one just happened to be NAV, because that’s what the consultant, a London-based freelancer by the name of Hannes Holst, implemented when he wrote the article.  (it’s our firm’s specialty as well, by way of full disclosure.)

In that project, Holst was tasked with replacing an existing ERP system with Dynamics NAV, and the plan was to do it on time and on budget – or under.  And they succeeded.  The three critical factors, in Holst’s retrospective were…

  1. Know what the business wants. In our own process at our firm, we label this the business process analysis, but call it what you will, you have to scope the requirements.  It’s the roadmap for all that follows.  It’s a serious (and yes, billable) engagement requiring both parties’ key staff to engage deeply in thinking about the client’s company, processes and goals.  Then, a roadmap is constructed that involves what, where, when, how and who, and guides the entire project team so they understand the goals, benchmarks and processes of that implementation

 

  1. Utilize the Dynamics NAV standard. NAV has been developed continuously for well over twenty years now, and covers all the functionality most any business could need today.  Standardized functionality has been applied all up and down the accounting workflow in NAV, and it works across many industries.  (While we specialize here in manufacturing and distribution, it’s equally adept at retail, service and many others.)  So wherever possible, Holst advises, align the business processes with the software.  This makes projects simpler, quicker and more agile.  Users can start working in some areas very quickly, as other pieces get added later.  (There are some caveats in this regard, but the advice is generally true.)  Finally, assess customizations in terms of impact to the company, which includes an overarching need, the budget, the need to continually maintain those modifications into the future, and the value of their overall ROI.  And when you do customize, wait a while, and then prioritize those “mods” from high to low when you determine which are truly needed.

 

  1. Hire an internal NAV expert. You can’t always do this of course, but you can have your most knowledgeable expert on the company’s inner-workings coordinating the project on the client side with the project leader from the consultant’s side.  A lot of issues can be resolved quickly when you have process- and software-knowledgeable participants on both sides of that support call.  That internal resource at the client side has a lot to do with landing your project on-time and/or on-budget.  They can recognize problems early on, unsnag project logjams, warn of impending potential pitfalls, and keep client-side implementers on-task and moving forward.  Your whole implementation benefits from the insights an internal expert can bring to bear, and having voices on both sides of the project management spectrum helps ensure that projects are kept honest, flowing, cooperative and, ultimately, successful.

 

Holst’s full, brief article can be found here (you have to join the forum, but it’s free):

 

 

 

Read Full Post »

Recently the folks at Panorama Consulting wrote an article about who should be on a company’s digital transformation project management team.  Included were the results of a study by two professors who came up with a clever way to think of the personality traits required of that team.  We’ll get to that in a moment, but first…

They first noted that teams can run from a very few players to as many as 15 or so.  Most, in our experience, have about 3 to 5 key members.  That team will develop a project charter to assign responsibilities and resources, both internal and external, throughout the project.  This steering committee decides which tasks can be handed off, and which (like final sign off on future-state business processes) cannot.  The charter defines how decisions are made, and by whom.

The team also addresses the fact that while major transformation is occurring, the business must still go on.  Day to day operations are ongoing, even as the new special project takes precedence, and senior managers need to determine how that’s going to work.  Overtime?  Suck it up?  Hire temps?  Wait for a slowdown in business?  Whatever the answer, it must be addressed at the outset, and adhered to thereafter.

In their article Panorama notes that…

“Some organizations build their project team based on who they believe to be the smartest or most technically-skilled. While technical expertise and operational knowledge are important, communication skills are also valuable, especially when the project team is tasked with executing an organizational change management plan to engage and train employees.”

Professors Kenneth Benne and Paul Sheats published a study, Functional Roles of Group Members, in which they identified key personality traits that contribute to strong teams. Here are five of those personality traits:

  • The Cheerleader encourages other project team members to participate and recognizes them for their contributions. This role is useful for encouraging engagement on both the project team and throughout the organization.
  • The Peacemaker helps project team members reach a consensus when compromise is necessary. Peacemakers focus on the success of the organization as a whole. This role is useful when defining and prioritizing business processes.
  • The Sergeant-at-Arms ensures the project team meets deadlines and expectations while adhering to the organization’s core values. This role can help develop strong project controls and governance and gently remind team members of these guidelines.
  • The Good-Humor Man relieves the tension and anxiety of digital transformation. The right amount of jest can lighten the mood and reenergize team members.
  • The Contrarian is a critical thinker and innovator who is not afraid to share his/her opinion. This role can challenge project team members to think about the project from a people and process perspective instead of a technical perspective. The contrarian can also ensure that the project team preserves the organization’s competitive advantage during business process management.

Make sense for you?  Worth thinking about, for sure.

 

Read Full Post »

Companies executing a digital transformation in an effort to keep up with the pace of business change today and all its competitive challenges need to consider a lot of strategies when doing so.  A recent article from Panorama Consulting reminds us that setting the right expectations comes first.

 

Starting with a statement of project scope, you need to then develop the business case – why are you implementing new technology in the first place? – and then work out the elements of ROI (return on investment), and the corresponding budget and timeline.  Clear understanding of expectations must then be communicated throughout the organization.

Timelines, let alone budgets, are often very difficult to estimate.  Changes to both are inevitable.  But you can help your planning by considering a few aspects that are often overlooked.  Among the key project tasks Panorama’s consultants advise organizations to remember are:

  • Quantifying specific benefits you hope to achieve, such as visibility into real-time data, visibility across functional areas, reduced inventory and decreased days to close
  • Developing a master data management strategy and data migration strategy
  • Conducting an organizational readiness assessment
  • Developing and executing an organizational change management plan
  • Assessing staffing needs for each phase of the project, and possibly augmenting your staff with outside resources
  • Working with functional leads to map current and future state business processes and identify pain points
  • Working with functional leads to define requirements, validate requirements and schedule software demos
  • Recruiting stakeholders from different departments, business units and locations to help define requirements
  • Distributing workshop guides to prepare employees for requirements gathering workshops
  • Prioritizing functional requirements into three categories (mandatory, value-add, nice to have)
  • Balancing the need for software customization with the cost of training
  • Reskilling employees whose jobs will become automated
  • Meeting with the vendor for an organizational design session

It’s a lot of ground to cover, but considering these details before you commit can save a lot of time, money and frustration, and go along ways towards ensuring your digital transformation project’s success.

 

Read Full Post »

The world of ERP, like all tech initiatives, is constantly evolving.  A recent opinion piece from Panorama Consulting suggests that in this light, ERP implementations — which have a “bad reputation” for being over-budget, over-time, and low on the ROI scale – are being replaced by “digital transformations,” a broader initiative designed to position the organization for future growth, accelerate competitive advantage and produce real ROI.

Our image above portrays some of the contrasts defined in Panorama’s post, found here.

They prescribe a change management strategy based on “large-scale change,” noting that if you’re after a “truly digital transformation,” then you must consider the large-scale change: “…that means you’re changing more than your technology – you’re undergoing large-scale change and fundamentally altering structures, processes and employees’ day-to-day jobs. If new technology is merely enhancing one of these elements, then you’re likely experiencing small-scale change.”

Like many initiatives, large-scale change requires three key elements:

  • preparing for change, including risk analysis and a readiness assessment and roadmap
  • managing the change, with a focus on communications, and overcoming resistance
  • reinforcing the change, where you gather employee feedback to assess results, root causes of resistance, and celebrate successes.

Key signposts for change management failure, according to Panorama include:

  • lack of executive sponsorship
  • ignoring the “people side” of change
  • lack of dedicated resources
  • ignoring resistance to change
  • no communications plan

When you think about it, those are many of the same hallmarks of failed ERP implementation plans as well.  There’s a familiar theme here, and in the end it’s really about the scale of change you’re trying to implement.  The larger the scale, or the greater the desire for ROI, r the more intense the focus on positioning for growth… the more executive talent, time and resources, as well as communications, strategy and roadmap creation become critical to a successful result.

Sometimes, the more things change, the more they stay the same.

 

Read Full Post »

The Internet of Things promises to transform the way humans, through their machines, interact with the Internet, and when you think about it, it’s already here.  Manufacturing is a case in point.

Today, sensors attached to shop floor equipment are capable of sending reams of production and equipment data back to the ERP systems, which hold that data in a repository for future use or analysis.

Handheld scanners are used to track the movement of parts, pieces and production.  Beyond that, they also aid warehouse workers in the movement — the picking, packing and shipping – of countless SKUs.  Everyone from the folks walking the floor to the folks in the front and back offices can have access to the same production and inventory information, in real time, at the same time.

Smartphones in the customer service and CRM arenas have made possible up-to-date information on all manner of data, from customer sales and orders to inventory quantities on-hand to sales reports across the territory or across the globe.  From checking into hotels to allowing physicians to check in on patient records from their phones and tablets, the interconnectedness of machines, ERP and the web has reached critical mass.

It’s the full-flowering of Bill Gates’ long-ago promise of IAYF: Information At Your Fingertips.

By 2020 according to one industry analyst, fully 95% of products are expected to be IoT enabled.  (We think that’s a bit optimistic, but their point is well taken nonetheless.)

All these advances have their advantages of course.  They save time – lots of it.  They save money – again, lots of it.  They speed up delivery, improve customer responsiveness, enable customers to become self-serving, and generally raise the level of satisfaction among a wide range of customers and their supporting companies.

For companies today frankly, there is little choice any more: adopt and adapt, or be left behind.  Sometimes the toughest question becomes: where do we start?  Luckily, there’s no shortage of consultants and solution providers willing and capable of providing the necessary guidance to get started.  About the only thing you can’t do any more is… wait.

 

 

Read Full Post »

Our cohorts at Panorama Consulting often write good pieces about the importance of business process change management, especially when it relates to firms in growth mode who also happen to be implementing success strategies and software systems aimed at supporting that growth.

Recently they penned a piece on the topic of what you can learn from your business process management mistakes.  Because we also spend our days reviewing firms’ business processes, we thought their words worth sharing with our audience.  You’ll find their original piece here.

 

Just as researchers search furiously for the cause of disasters involving ships and planes, they suggest we too search for causes behind operational disruptions, which often cause morale problems among employees, inadequate software implementations and customizations, frustration all around, and low benefit realization.

To learn from our failures, the authors suggest we

  • Forgive – “Take a deep breath, forgive ourselves and others” to gain a clear head.
  • Analyze – Conduct a “lessons learned meeting to review project deliverables. Quantifying the direct and indirect costs in terms of time and money will give you an idea of the benefits you’ll need to realize to achieve a positive ROI on failure.”
  • Disseminate – Share lessons learned across the organization.

Panorama notes that “operational disruptions can be avoided by developing an effective business process management plan.”  They suggest including…

  • Business Process Mapping. We wholeheartedly concur, because any successful implementation always starts here.  At a high level, we map current processes and future-state processes, looking for technology touch points, redundancies (and ways to eliminate them), and how to do away with multiple and sometimes proprietary silos of information.  You reengineer your processes in order to optimize your workflows, both human and machine, to best capture the talents of your organization and the areas where you lend the most value to your customers.
  • Organization Change Management. Implementing new business solutions can often result in a decrease in productivity initially.  As the authors note: “Business process management cannot succeed without customized training and targeted employee communication, both of which should begin before software selection.”
  • Continuous Improvement. It’s a mentality.  And it will help ensure that you maintain optimized processes consistently into the future.  Set KPIs and other benchmarks which allow you to record progress and build toward improved performance.  Measure regularly.  If you can’t measure it, you can’t improve it.

Good advice all to anyone implementing process change, organizational change, or structural changes from software to process management.

 

Read Full Post »

An ERP software provider called Abas (abas-erp.com) recently released a paper called “Writing a Better RFP” intended to advise companies on what’s wrong with most of their RFP processes, and how they might do better.  While we have no affiliation or relationship with Abas, we thought their advice was very wise and up-to-date in tackling the old paradigm for software selection.

Abas points out two flaws in most companies’ current Request for Proposal strategies:

  1. Putting excessive internal resources into filling out unnecessarily long RFP templates, and
  2. Paying third-party RFP specialists to create complex RFPs.

They make the point that these methods do little more than to make the process very expensive and bog down the selection process – and are of little help in selecting a vendor anyway.

The article’s author goes on to point out that today there are a great many common core functionalities across ERP packages.  Your goal should be to “reveal areas of competitive differentiation between potential vendors.”

So skip the generic questions they advise (which virtually all of today’s modern packages can handle) and cut to the questions that really matter to your company’s work, and how you run the business. They give the example of: “Is the ERP system capable of recommending an available-to-promise date or hard allocating inventory at order entry?”  You get the idea: ask the questions that are truly your choke points, or that relate to your competitive differentiators, to understand how the solution could improve your workflows.

Also, they advise: ask questions that seek to determine whether the vendor has experience and domain knowledge in your particular industry.  In this regard, all systems – and all vendors – are definitely not the same.  You want not just software fit, you want implementation expertise.

Abas points out – and we could not agree more – that RFPs are far too lengthy, and we too often find them filled with hundreds of largely irrelevant, or at least ‘generic’ questions that waste everyone’s time, and do nothing to help you establish clear winners or losers.  They further advise to give more ‘weight’ to the more important questions (to your business) and to the perceived expertise of your provider, and less weight to many of the generic components that most any system can handle, so you’re weighing in a manner that’s relevant to your most important needs.

What’s the right number of questions?  Believe it or not, Abas suggests (and again, biased or not – we prefer to think of it as ‘experienced’ – we couldn’t agree more…) that about 10 to 15, industry-specific  questions will tell you all you need to know to differentiate among vendors. 

Your RFP should be proactive, not reactive.  It should ask the questions most critical to the issues your business faces – and not just short-term, but down the road as well.  What emerging technologies might cause you disruption?  How well will your solution scale, or morph to fit your possible future needs?  Can it be changed and modified easily, and by whom?  All good food for thought.

And finally, ask yourself: Are you looking at cost, or value?  Sure, cost is important and the bottom line matters.  But focusing on cost alone is short-sighted.  Look at the bigger picture: total cost of ownership (TCO), along with the value proposition to your business over the next ten years, not the next two or three.

 

Read Full Post »

Older Posts »