Share:   twitter icon facebook icon linkedin icon linkedin icon
Share this page:   email
BACK TO THE BLOG

The ERP Digitization Journey for Living Goods

BY Taylor Capizola • August 29, 2018

Part 1: Building the Foundation

By Alfred Wise, Director of Strategic Growth Initiatives

Note:  I wanted to share some key insights gleaned from setting up an Enterprise Resource Planning system and digitizing the operations of Living Goods in two posts, with a focus on documenting all the things I wish I had known before we started.  In Part 1, I explore how we selected the system and process-mapping business areas.  In Part 2, I’ll review how we approached training, change management, and data migration, as we prepare to go-live with the system.

Mobile health (mHealth) has long been a cornerstone of Living Goods’ approach to effective community health: after years employing SMS technology, 2015 we partnered with Medic Mobile to an Android-based tool called Smart Health that enables thousands of Community Health Workers (CHWs) across Kenya and Uganda to educate, assess, diagnose, treat and effectively follow up key health issues for sick children and new mothers. 

Like many NGOs, however, our back-office operations were cobbled together.  We had outgrown our QuickBooks System, juggled numerous Excel spreadsheets to track everything from employee leave to vendors, and had pockets of secrets known and guarded by various employees in different locations.  When key staff moved on, we’d regularly unearth critical processes known only by that individual.

Over the past four years, as we scaled from 400 to nearly 4,000 CHWs and more than 350 staff, and launched a plan to grow our impact another 10-fold by 2021, we knew we needed robust and reliable systems that would support our growth.  Our current systems were at the breaking point.  We decided to go for end-to-end business digitization, and that started with an Enterprise Resource Planning (ERP) system that would link finance, supply chain, HR, and all back-office operations.

Selecting a System

We started with a requirements assessment.  USAID’s Development Innovation Ventures division as well as the COMO Foundation supported us with consultants who surveyed all our teams in Kenya and Uganda, and helped us draft a Request for Proposal, and a requirements document that outlined 500 core business needs. As a non-profit social enterprise, we have all the needs of any NGO – detailed program and grant management and tracking – coupled with all the needs of a retailer: procurement, inventory management, and a robust Point-of-Sale system.  Another complicating factor is that most of our operations take place in East Africa.  We needed a system that met statutory requirements for payroll processing across different counties while operating in places with less-than-reliable electricity and connectivity.

We also needed a mobile Point-of-Sale (POS) system that would work in resource-poor settings to support CHWs selling medications and products to their neighbors door-to-door.  As the number of Community Health Workers that Living Goods supports has grown, so too has the radius of coverage around our branch system.  For years, we relied on a desktop-based point of sale system at each branch.  CHWs either had to procure their supplies at our branches, or our branch staff would compile records CHWs wrote out on scraps of handwritten paper by retyping the sales into the POS. A tablet-based system that works in the field would allow us to scale without having to continually build new branches. Finally, the system absolutely had to be as simple to use as possible.

Our needs, it seemed, could not readily be met by any standard, preconfigured system. And we realized we were selecting more than a system, but also an implementer to partner with over the long term.  This was a serious courtship, and we had to meet the extended family before making a decision.

The RFP garnered a dozen proposals, most more than 300 pages of cut-and-pasted capability statements, staff bios, and brochures with graphics that made their systems look like they powered rockets.  Each proposal promised a solution that was perfect for our needs. Our Tech Committee finally short-listed a few systems, including Microsoft Dynamics 365, Microsoft Dynamics NAV, Oracle Netsuite, SAP BusinessByDesign, and Sage X3.

We decided early on that we preferred a cloud-based ERP solution, as we didn’t have the technical expertise to manage onsite servers 24/7, or the desire to invest in servers and backup systems.

In the end, we selected Microsoft Dynamics 365. It is a relatively new system that integrates with all the Microsoft Office tools that we use day-to-day, such as Excel and Outlook.  We met with the Microsoft team in Nairobi to get their thoughts on the implementers, and ultimately selected Impax Business Solutions, a firm with a good reputation and a robust team, who seemed eager to work with us.

Laying the Foundation

One decision, largely a result of circumstance, has proven fortuitous.  We had a senior team member (me) who moved from Uganda to Kenya for family reasons. While not a techie, I have run operations and finance teams, so was plugged in as ERP Project Lead.  In hindsight, this was a sound decision as you need a project owner who lives and breathes it to push it through, especially when everyone becomes frustrated.

The first step in digitizing an organization is mapping detailed business processes. We did it in two steps. First “Functional Requirements Documents” or FRDs were developed for each key area, and these served as the framework for a “Design Document,” which lay out the technical specifications. The implementers are generally interested in getting straight to coding, but we made the decision to invest time in this process and brought in consultants who specialize in business process design.  As we began to map out processes, it became apparent that over time, each country had developed different processes organically, or sometimes not at all.

Mapping business processes serve as a forcing function, requiring a high level of detail to get user workflows and permissions clearly identified, and ultimately as a means to think through effective policies and processes that will support future growth.  If you want to code something into a system, it has to be clearly defined first.

We developed seven FRDs: for Finance, Procurement, Distribution, HR and Payroll, Point of Sale, Recruitment, and Customer Relationship Management (CRM) for our Business Development team.   Each department needed to think deeply about their current processes and what they needed going forward.

But just as coding began, and we initiated some early training sessions, we realized we had to refocus once again – all of our FRDs wound up being a starting point, rather than a concrete final plan. Despite all the time we spent process mapping, significant changes, customizations, and decisions still emerged at the training sessions. We realized it was nearly impossible for staff to fully engage or really articulate all of their needs until they were able to see a true deliverable on a computer screen. In retrospect, more time was needed for early-group testing, modifications, and retesting. We needed staff to interact with the system right away as a way of enabling them to articulate their needs more clearly. While distressing to anyone trying to adhere to a timeline (me), it taking the time to truly understand their needs and customize the system accordingly enabled greater team-ownership and the effective design of the modules before we go live.

One of the most positive unanticipated outcomes was just how much more we were able to achieve through our ERP system as a result of training sessions that unleashed the incredible creative energy of our staff. We needed to harness the insights of our end users – who understand their actual needs most deeply, and get them to start using the system – so that we maximize the potential for this initiative. An excited team generates lots of new ideas: How can we do stock reconciliations at month-end and take stock directly in the system? How do we get our branch team using analytics to monitor spend against budget? How do we use the Project Management functionality to better map expenses against restricted funds? This quest for even more functionality within the ERP system than we had originally imagined is a good problem to have and is driving our future steps on the project.

Lessons Learned – Part 1

  1. Request for Proposal. Spend time on the RFP to identify detailed needs. This listing of needs will serve as a “Project Charter” and guide the implementation over the long term.
  2. Implementer. Understand the strengths of the implementers, not just the system, with reference checks, including directly with the software company.
  3. Anticipate all costs over the longer term (3 to 5 years) including that of the implementer, licensing, and support.
  4. Sometimes the solutions you need don’t exist, and must be created. Living Goods’ model revolves around the ability for our CHWs and their supervisors to operate in the field, moving door-to-door in their communities. Our POS system needed to also work in the field, with the ability to operate offline and upload data when connectivity is available. We had to develop a POS solution to work on a tablet using Microsoft apps. This was a critical business need for Living Goods and warranted a bespoke development.
  5. Plan for several months of Business Process Mapping, and involve all departments in this process. Developing the Functional Requirements Documents forces the team to  think through  organizational processes and workflows. This is also the time to identify policy gaps and create new organizational policies.
  6. Testing. Allow for several rounds of “Conference Room Pilots” with adequate time for suggestions to be incorporated and tested again.
  7. Issue Logs. Keep a detailed Issue Log of suggestions that arise from all teams, and track that all requested changes are made by the implementer.
  8. Project Lead. Have a dedicated Project Lead, with at least the majority of his or her time focused on the implementation.

 

BACK TO THE BLOG