For many, the idea that software would drive business processes is problematic. The thinking is that software should support good processes, not drive their design. This made great sense when software was designed to meet the need from scratch or could easily be customized to meet the process design. The result, however, was custom software that needed to be maintained, or worse, customized vendor software that needed to be upgraded and maintained. The more recent trend with modern cloud solutions is to adopt the best practice processes embedded in SaaS ERP systems. The assumption here is that the ERP software vendor has built best-practice processes into their products.
Over the last couple of years, Tambellini has observed more institutions able to adopt the configurable processes built into cloud ERP packages and to align the detailed process design to the implementation projects. This method still leaves quite a bit of flexibility for the institution in designing the final process but has guardrails on overall process design.
As is typical for an ERP software implementation, most institutions are taking the opportunity to modernize processes as they implement. These modernizations range from moving to shared services to standardizing processes across the organization or system. Business areas have typically been eyeing more modern processes but could not get the budget or the leadership support to make major changes. A major system change provides the project infrastructure and the opportunity to design new processes. It also provides a change management and project management framework to ensure the process can be rolled out successfully. Some institutions have even aligned service center implementation to their ERP rollouts for the same reasons. For most organizations, implementing ERP is a generational opportunity to make business changes.
Given this situation, what can, and should, institutions do regarding process design before their ERP project kicks off before the software has been selected? Tambellini has developed a few recommendations for institutions that are considering investing in business process redesign before ERP implementations.
- Define your strategic objectives. Whether service center organization, process standardization, or organizational consolidation, defining these outcomes before selecting software or designing and budgeting an implementation are critical. They can have a profound effect on every aspect of an ERP change.
Each business area, aligned with an overriding executive vision, should be outlined to provide the leaders and teams direction for decisions. There are multiple methods to get to these objectives, two of which we describe below.
- Define aspirational, data-driven objectives. For every part of the organization, consider setting targets for measurable success. These very objective goals can align process and technology design, selection, and implementation. They can also ensure that reporting and analytics are defined and created to measure progress toward these goals over time. An example of such an objective is a reduction of time to process a purchase order from x days to y hours.
- Define high-level operational models. Where possible, using the goals and targets already identified, operating models can be designed. It is critical not to spend too much time on detailed models since the software will impact some of the details required (e.g., breakdowns between operational role responsibilities). To follow the previous example, the definition of a high-level operational model for purchasing would be to automate requests and approvals, dependent on type and amount of purchase.
- Identify your problem areas. It is critical to identify pain-points of students, faculty, and staff who are “customers” of processes. You will undoubtedly find common problems across the institution. In some cases, the most that can be done at this stage is to identify and quantify problems, stating them as objectives. It is critical to identify pain-points of students, faculty and staff who are “customers” of processes. In going through the detailed definition of processes and configuration of software during the project, having these problem areas visible to all helps to reduce or eliminate them during design. Short-term solutions may come up in some cases, and there may be time to fix some of them before ERP activities begin. Though care should be taken at this stage, if there is proper governance around changes being made, some solutions can be quick and inexpensive.
Considerations before starting
This work can be energizing for teams, bringing together problem-solvers in an open environment, and removing some of the da-to-day constraints in problem-solving. In doing so, there are a few caveats.
- Stay out of the weeds. Designing detailed processes before software selection and potentially years before they can be implemented can cause a great deal of wasted time and frustration on the part of teams. Caution the groups you gather not to get into these details and lay out the context of the effort to ensure they understand the goals.
- Build cross-functional teams. Business functional are inter-related, especially when looking at broad topics and strategic objectives. Ensure that cross-functional representatives are present to ensure alignment between teams, and consideration of impacts and other strategic goals in setting direction.
- Context matters. Before gathering a team to work on this, ensure executives, and leaders are aligned on what, why, and how the effort will proceed. Providing clear direction, context and expectations is critical to the success of this kind of effort, including any guardrails where the teams should not go.
- Identify what differentiates your institution from others. Sometimes, those unique characteristics and programs require processes that modern solutions don’t support. It is important to identify and understand them.
- Get ahead of the changes. If a business process change requires policy changes or Board of Trustee or Faculty Governance approval, know what is required and when to facilitate the change.
Though business process work is interrelated to implementation work, some activities can be taken on before the implementation work begins that can smooth out the process work during the project. There may be simple process fixes that can be made without significant systems changes. If undertaken with good awareness, transparency and partnership, this work can be very beneficial to the institution.
