FAQ: Change Management

An initiative with Lokad aims to optimize the client’s supply chain with superior, automated decision-making - typically replacing mundane daily tasks such as purchase orders and stock allocation choices. This page addresses questions and concerns about the change this initiative brings, and how to effectively manage it. Lokad’s experts remain, at all times, available to help clients navigate the process.

Intended audience: The supply chain and/or planning departments.
Last modified: December 19th, 2023

Overview of Change Management

Quantitative Supply Chain (QSC), as pioneered and advocated by Lokad, diverges significantly from the traditional perspective. The differences are both essential and the core reasons why Lokad can deliver such drastic supply chain improvements. That said, the change management associated with implementing a QSC initiative is easier than our clients typically think.

For example, Lokad eliminates many unnecessary touchpoints and processes, rather than merely replacing waste with different waste. Thus, the change to be managed is typically twofold: first, adjusting to the fact that mundane, repetitive supply chain decisions are now automated; second, accepting that the quality of those automated decisions exceed what employees used to be able to achieve with alternative tools (legacy systems, spreadsheets, and frequently a bit of both).

A QSC initiative is spearheaded by Lokad’s Supply Chain Scientists. These experts consolidate many roles that would typically be performed by multiple people in similar initiatives with other software vendors. A Supply Chain Scientist functions as a system integrator, data engineer, business analyst, data scientist, supply chain expert, and project manager (amongst other roles). The Supply Chain Scientists (SCSs) provide all the necessary coaching, training, guidance, and support for clients to embrace Lokad’s quantitative supply chain approach.

The successful deployment of Lokad (in production) typically yields two notable outcomes: substantial savings through better supply chain decisions, and substantial productivity savings through (largely) automated supply chain decisions.

In terms of change management, supply chain savings are typically a non-issue. The company might ultimately decide to reinvest the freed working capital somewhere else, but this sort of decision normally exceeds the scope of the Lokad initiative. However, the considerable productivity savings generated by Lokad are typically re-invested in other tasks that bring much more added value for the client company than the legacy process.

In brief, before Lokad, the activities of supply chain practitioners within the client company are almost exclusively inward-looking: produce a forecast, turn the forecast into a plan, adjust min/max stock levels on SKUs, compose purchase orders/production orders/stock movement, etc.

Once Lokad is in production, most activities are outward-looking: identify what clients perceive as quality of service, identify what suppliers perceive as an obstacle to lower the price further, identify what transporters perceive as the root causes for their unreliability, etc.

These insights are then continuously incorporated into Lokad’s solution through the ongoing support of the SCSs.

For supply chain executives, the biggest change is the (by and large) elimination of ongoing firefighting. Lokad’s solution delivers automated decisions designed to deal with pesky edge cases, thus substantially reducing the bandwidth executives must dedicate to parsing erratic market behavior. This frees supply chain executives to strategize supply chain goals and projects, as opposed to micro-managing the ongoing consequences of suboptimal decisions.

Frequently Asked Questions (FAQ)

1. Project Implementation & Management

1.1 Do you offer implementation project management services?

Yes. These services are delivered by Lokad’s Supply Chain Scientists (SCSs). These experts not only manage the implementation, but also spearhead the initiative with the client company. This includes many tasks such as providing quantitative reassurance to the supply chain management to demonstrate the validity of Lokad’s numerical recipes prior to their deployment. SCSs also provide training materials to support the adoption of Lokad’s recommended practices and processes within the client company.

Beyond that, these experts remain committed to the long-term success of the initiative beyond the initial implementation, providing ongoing support as the initiative transitions to its ‘continuous improvement’ phase.

See Lokad’s lectures on the Supply Chain Scientist and A day in the life of a Supply Chain Scientist for more information on the SCS’ role in the optimization process.

1.2 What is your implementation timeline and steps or phases included in this timeline? What are the goals of each phase (starting from Project Implementation Kick-off to Go-Live)?

From start to finish, the implementation usually takes about 6 months. Lokad distinguishes the onboarding phase from the production phase. The goal of the onboarding phase is to get Lokad’s numerical recipe into production. By the end of the onboarding phase, the supply chain decisions of interest (as defined in collaboration with the client) should be robotized. However, the automation is typically only a side effect (although a very visible one) of the actual intent: to improve the supply chain performance. The goal of the ‘production’ phase is to continuously refine, improve and re-align the numerical recipes, the ones that enable the automation in the first place.

Breakdown of timeline

The onboarding phase typically lasts 6 months and can be split in three sub-phases of 2 months.

The first sub-phase is the setup of the data pipeline. The goal is to create a fully automated pipeline for the extraction of client data to Lokad. The two most demanding aspects of the data pipeline are establishing the ‘semantics’ of the data and making the pipelining process itself (near) perfectly reliable. A data pipeline, as opposed to a one-shot data extraction, is fundamental to keeping the supply chain recommendations Lokad generates relevant to the client’s present-day business concerns.
The second sub-phase is the design of the client’s unique numerical recipe(s) - the pieces of software logic that drive the supply chain decisions. The goal is to achieve recipes that are consistent, reliable, and no-nonsense. Drafting the initial numerical recipes is swift, typically lasting no longer than a week or two. However, these drafts are just starting-points, and they are rapidly improved over successive iterations by the Supply Chain Scientist(s) in charge of the respective account. This quickly eliminates pesky edge cases present in the initial drafts.
The third sub-phase is the dual run. The numerical recipe does not produce nonsense anymore, and the economic drivers steering the optimization have been agreed on. However, the recipe is not production-grade yet. In order to move forward, a dual run is engaged. The numerical recipe is run side-by-side with the legacy process. As the recipe is automated, the organizational overhead is low. Every day, supply chain practitioners can compare the decisions and see how patterns (e.g., seasonality) unfold. Through several weeks of dual run, trust is acquired to proceed with the production roll-out.

At the end of the onboarding phase - and if all steps have been satisfied - the production rollout starts. This rollout consists of letting the automation take over the legacy process. This takeover can also be phased, depending on the client’s capacity to oversee the necessary change management.

See timeline overview for a more detailed breakdown of each step involved in the optimization process.

1.3 Does Lokad document and publish a project management plan detailing the project’s scope, schedule/timelines, critical milestones, resourcing, deliverables, accountabilities, cost management plan, quality management plan, risk management plan, and stakeholder management and communication plan?

Yes. All those elements, and more, are gathered in a unique Joint Procedure Manual (JPM) for the initiative. The Supply Chain Scientists (SCSs) are in charge of initiating and maintaining the JPM for the entire duration of the initiative.

Lokad’s JPM focuses on the ‘why?’ questions. JPMs are well-written and intended to be largely accessible even to less-technical and/or non-specialist audiences. The JPM captures the essence of the intent behind the initiative, and consolidates fundamental insights as they are acquired along the initiative itself.

Lokad’s take is that many (if not most) enterprise initiatives are hindered by the production of unhelpful documents, which are, in practice, impossible to read (i.e., they are tedious or impenetrably technical). Such documents serve no purpose besides ticking made-up boxes. Furthermore, many third-parties (e.g., integrators, consultants, and even the in-house bureaucracy) have a severe tendency to favor quantity over quality when it comes to the documentation of the project.

In contrast, Lokad’s JPMs are intended to be both readable and read. JPMs are tools used by the SCSs themselves to manage the initiative. While we do have extensive guidelines about what is expected to be found in a JPM, it is ultimately up to the SCSs to make sound judgment calls about what needs the most attention and effort considering the specifics of the initiative.

See the lecture Writing for Supply Chains for more information on Lokad’s documentation ethos.

1.4 Is Lokad responsible for maintaining and baselining the project management plan, subject to approval(s) from the project steering committee? Should any deviations from the plan arise, will you clearly communicate them along with mitigation options?

Yes. The listed responsibilities are managed by Lokad’s Supply Chain Scientists (SCSs). The fine print of the management of communication with the client company is typically dependent on, and defined in, the contractual terms for the initiative itself.

There are occasionally significantly more employees involved in the project client-side than Lokad-side, thus to improve the productivity of the SCSs handling the account, many of our clients designate a single point of contact for the initiative. This person - or small team - is charged with relaying relevant information to - and seeking relevant feedback from - all the parties involved in the project client-side.

For a particularly complex initiative, Lokad installs a dedicated steering committee composed of key members from both Lokad and the client company. Though this meeting serves as a mechanism to secure formal approval, most of the substantive work happens outside of the committee itself. SCSs typically engage in daily interactions with various teams client-side. Those teams are updated continuously about any deviations from the plan, and they make sure the whole initiative stays on track. These daily interactions are a far more effective way of discussing and overcoming technical issues as they arise, rather than trying to investigate large batches of problems during a steering committee session. Hence, the steering committee, as such, acts as a supervising body rather than as a think-tank for the initiative.

Note: Quantitative supply chain initiatives are known to frequently encounter “positive deviations”. These are beneficial surprises in the recipe that reveal themselves during the ongoing maintenance of the initiative. Essentially, they are opportunities that are too good to pass up. As such, a key benefit of Lokad’s approach to communication is the ability to promptly and efficiently relay these positive deviations to the client as they arise, thus significantly increasing the impact and agility of the initiative.

1.5 Will you document the communication plan, which includes daily stand-ups, weekly working group status reports and review sessions, as well as monthly steering committee reports and review sessions? Will you outline the escalation criteria and ensure mutual agreement between the client company and Lokad on these details?

Yes. Lokad’s Supply Chain Scientists (SCSs) are responsible for these duties. The details of communication management within the client company are typically dependent on contractual terms for the initiative itself.

Lokad willingly participates in daily stand-ups when onsite at the client company headquarters. Usually, however, our SCSs operate at the Lokad offices.

We consolidate all the documentation of the initiative into a Joint Procedure Manual (JPM) that effectively serves as a comprehensive guide for the entire project. The JPM includes the notes of all work sessions, including steering committee reports (when applicable).

While Lokad does clarify the escalation criteria and guidelines, it is worth highlighting that a Senior SCS at Lokad is expected to handle any questions or concerns about the initiative. Thus, regarding escalation, the resolution of a troubling issue is typically escalated from a Junior SCS to a Senior one. This has historically proved sufficient with very few situations requiring further escalation.

Lokad views all issues - however minor in appearance – as deserving of in-depth analysis. Though their effects are easy to resolve, minor issues may pose future problems if the root causes are not understood and addressed. This prevents a minor issue from becoming a recurring one. Thus, Lokad favors putting highly capable people on the frontline capable of addressing both the immediate problem and identifying underlying root causes. This approach is preferable to relying on untrained support staff who continuously address the same issues - a pattern too frequently adopted by many enterprise software vendors.

Thus, Lokad’s concise escalation process is intentional, ensuring swift and lasting resolutions.

1.6 Will you ensure that the project management plan is signed off by all stakeholders as part of the project initiation phase?

Yes. More generally, Lokad’s Supply Chain Scientists (SCSs) follow whatever process has been negotiated and agreed upon with each client – as per formal contractual terms. This principle remains applicable throughout the initiative, from start to conclusion. The initiation of the project is certainly important, though given Lokad does not require a long-term commitment from the first day, this matter is of lesser concern – especially when compared to our competitors.

It should be noted that we have never observed a supply chain perform poorly due to a ‘lack’ of bureaucracy and other frivolous processes. On the contrary, unnecessary bureaucracies and inane processes are the most common problems found in modern supply chains - present even in companies that appear to have otherwise high-performing supply chains.

1.7 Will you deploy a dedicated project manager from Lokad to be based at the client company’s headquarters, accompanied by product subject matter experts, business analysts, and technical interface experts?

Yes, if such provisions are part of the agreed contractual terms for the initiative. While Lokad is not opposed to stationing employees onsite at the client company’s headquarters, it naturally increases the cost of the initiative. Most of our initiatives are carried out remotely, and supported by monthly or quarterly visits depending on the scale of the initiative. This practice is usually perceived by all parties as more efficient than stationing Lokad employees at the client’s office(s) all the time. It should be noted that, even if Lokad does agree to station a permanent team at the client company’s headquarters, the employees will rotate over time.

Such practices benefit all involved, as Lokad’s Supply Chain Scientists (SCSs) are subject to an ongoing training program. This program is critical to ensure that our employee continue to acquire new skills or refining old ones regardless of experience or seniority. While we observe that many enterprise vendors allow their employees to operate for months, if not years, at remote client sites, Lokad is convinced that this practice is not compatible with the reliable and efficient provision of high-quality training programs.

In particular, one of the greatest strengths of Lokad’s SCSs is their exceptionally diverse and broad skill set. Each SCS is trained to act in a variety of roles, such as: subject matter expert, business analyst, technical interface expert, data scientist, and supply chain consultant. These functions would normally be fulfilled by multiple employees and result in a significant increase in cost to the client. At Lokad, each SCS provides all these services.

As a result, SCSs tend to be vastly more productive (fewer people tend to mean less communication friction), as well as yield higher performance levels. In reality, supply chains are critically dependent on end-to-end consistency, something that is much easier to achieve with a low headcount.

1.8 During the implementation phase, what organization do you propose? Where should resources be allocated?

For a typical initiative at Lokad, we recommend that the client company assigns a seasoned supply chain practitioner as the coordinator of the initiative, and also that it appoints a supply chain executive as the supervisor of the initiative. The coordinator serves as the point of contact between Lokad’s team of Supply Chain Scientists (SCSs) and the client company. The coordinator will initially relay the requests for information, and later relay the requests for feedback. In parallel, Lokad’s SCSs work with the numerical recipes aimed at producing the supply chain decisions of interest.

We recommend a weekly meeting to review the progress of the initiative until the onboarding phase has been completed. This meeting is systematically attended by the coordinator, the supervisor, and the account’s primary SCS from Lokad. Other participants may join as needed, but their continuous presence is usually not necessary throughout the implementation/onboarding phase.

Some IT resources must be allocated to the setup of the data pipeline at the very beginning of the initiative. Lokad is more efficient than most of its peers in this regard. For example, we automatically and directly extract the client’s transactional data, without any cleaning or preparation required client-side. Unless the client company is experiencing vendor lock-in, this technical setup requires less than 4 weeks of work for a single contributor - and sometimes much less when a data lake is already in place.

Then, SCSs will need to collect qualitative insights about the existing processes, and the details of all the supply chain priorities and constraints. A series of interviews, facilitated by the coordinators, will typically take place to support this process. Later, once the SCSs have developed the numerical recipe(s), another series of interviews will occur to review the figures generated by those recipes and to allow the SCSs to refine and improve them.

The input of the supervisor is important both to align Lokad with the high-level strategy pursued by the company and to prevent the initiative from stalling due to indecision. For example, Lokad can propose various options to model the costs associated with the lack of quality of service. We can explain the advantages and disadvantages of these options in non-technical terms, but ultimately, a few strategic choices have to be made.

Naturally, all of the above depends on the specific needs of the initiative. We are open to other organizational approaches if they better suit the specific context and goals of the client company.

For more information, Lokad has several lectures dedicated to the tactical and strategic execution of a successful supply chain optimization.

2. Resource Management & Requirements

2.1 What are the manpower requirements for project implementation at the client company, specifically the number of resources and their expertise level? Can you precisely define the number of resources for each phase and sub-phase of the project?

A typical Lokad initiative requires approximately 0.5 to 2 FTE (full-time equivalent) employee resources from the client company during the first 6 months – a.k.a., the onboarding phase. Once the initiative enters production, a reasonable estimate is the project will still require at least 0.25 FTE. Naturally, these estimates vary substantially given the size and complexity of the client company and their specific supply chain needs.

In terms of resources required at each stage of a “typical” initiative, during the onboarding phase we have:

Months 1 and 2: The setup of the data pipeline requires 4 weeks of full-time effort from a data officer, typically employed by the client’s IT. The data officer should be quite familiar with the applicative landscape of the client company. This requirement can be decreased if a data lake is already in place, but conversely, it will be increased if the data pipeline has to cope with multiple business systems (e.g., 1 ERP per country). Once the data pipeline is up and running, its maintenance should not require more than a few hours per month from the data officer.
Months 3 and 4: Designing the numerical recipe requires 2 or 3 days per week from the coordinator (client-side) of the initiative, a minimum of 10 hours per week from various supply chain practitioners for providing high-level insights, and later to provide feedback on the figures produced by Lokad. The coordinator is expected to be familiar with the company and its supply chain, and to be at ease with analytical work. However, this position does not require specialized IT or specific data science skills. The weekly review of the initiative requires half a day per week from a supply chain executive.
Months 5 and 6: The requirements are essentially the same as the previous phase, however, the focus changes. The coordinator now spends most of their time preparing the proper roll-out and communicating with all the impacted supply chain practitioners. Similarly, the supply chain executive supervises the internal change management related to new processes arising from Lokad’s initiative.

2.2 Do you ensure that adequate manpower is planned to support the product transition?

Yes. As a rule of thumb, Lokad recommends keeping the same amount of resources (e.g., the same Supply Chain Scientists), while transitioning from the onboarding phase to the production phase. The potential return on investment of a well-maintained and continuously improved solution is substantial. It is a mistake to approach the resolution of such challenges with a set-and-forget mindset, as any technical solution will inevitably - and continuously - drift toward irrelevance and obsolescence if not properly monitored and maintained.

It is worth noting that, given Lokad automates supply chain decisions, there is no strict urgency in retraining all the client’s supply chain practitioners with a new process to keep the supply chain wheels spinning - the automation itself is designed to take care of that. As a result, it is not unusual for the complete overhaul of the client’s supply chain organization - triggered by Lokad’s initiative - to be completed mere months after the project goes live.

This streamlined approach stands in stark contrast to the large - and costly - “task forces” often required by enterprise software vendors to go live.

2.3 Can you guarantee that sufficient manpower and knowledge product (KP) resources are available onsite at the client company headquarters to support the product transition?

Yes, such provisions and requirements are covered by the specific, mutually agreed contractual terms of the initiative.

2.4 Do you arrange Requirements Review sessions with business product owners to elicit and document requirements?

Yes. One of the first goals of the Supply Chain Scientist is to acquire all the necessary insights about the client’s supply chain. This process is typically conducted through interviews with relevant stakeholders, including the business product owners. We also try to carefully review existing documents (when available), in order to make the most of those interviews.

However, Lokad’s prime concern is understanding the ‘problem’ being investigated, which is something not always aided by listing ‘requirements’. For example, if a client mentions that they require special handling of ‘slow movers’, we understand that low volume is a concern to be addressed. However, special-casing those SKUs is only one of the many options that is available to us to address this concern.

In this example, our preference would be to determine the true nature of the ‘slow movers’. In fact, after investigating the client’s supply chain pain points, it may be the case that ‘slow movers’ are SKUs that have been improperly priced, bundled and/or allocated. Once the problem (slow movers) is better understood, it changes the intervention strategy entirely - often making it easier to address.

As such, though Lokad elicits and documents all client requirements, our approach emphasizes discovering the true nature of the problem, rather than accepting at face value the current state of the client’s supply chain.

See Fall in Love with the Problem, Not the Solution for more on the problem-solution dichotomy.

Yes. These estimates are typically included in our initial commercial proposal. If a workshop is organized to prepare the initiative, we will use the information from the workshop to refine our proposal further.

The Lokad platform is programmatic. Thus, the implementation is intended to be supported by scripts, written in Envision, our DSL (domain-specific programming language) dedicated to the predictive optimization of supply chains. As a result, Lokad is especially well-suited to deliver bespoke features and interfaces, whether those interfaces are intended for people or for the business systems of the client company.

Unlike most enterprise software, programmability is a core feature for Lokad. The aforementioned Envision scripts are not a ‘customization’ of the Lokad solution in the usual sense. Nor is the presence of those scripts a departure from the mainline development branch of the Lokad solution. Rather, the rich programmability of Lokad is the intended implementation path.

As a result, there is an exceedingly high degree of certainty attached to our estimates (costs, schedule, etc.). The vast majority of projects stay within estimates/initial budget (in all senses). This stands in contrast to several of Lokad’s competitors, for whom costly delays and reformulations of terms is common.

See Case Study on Lidl’s €500 Million SAP Debacle for more on this point.

2.6 Will you implement and maintain a reasonable retention strategy designed to retain key personnel performing the services for the agreement term? Will you also maintain active succession plans for each of Lokad’s key personnel positions?

Yes. We retain for employees 3.5 years on average, which is nearly twice the employment tenure compared to similar cohorts (talented engineers in IT, or IT-adjacent domains) in similar markets (North America and Western Europe). This segment of the job market is fiercely competitive and, while there is always room for improvement, this puts Lokad well above most of our competitors. As a result, most of Lokad’s initiatives benefit from having the same Supply Chain Scientists (SCSs) from one year to the next.

This retention is attributable to competitive salaries and Lokad’s continuous investment in training its teams. In particular, the supply chain content published by Lokad on its own website, in particular our series of supply chain lectures, can be seen as a by-product of Lokad’s focus on training its own staff. Generally, enterprise software vendors that do not have public training materials almost never have private training materials either (even if they will invariably claim the opposite).

In terms of succession plans, we have two important practices at play. First, every Lokad initiative comes with a Joint Procedure Manual (JPM). The JPM is the primary document used by a new SCS to become quickly familiar with all the relevant insights and technicalities of the initiative. Second, every initiative has - at all times - both a primary and secondary SCS. Even if the secondary SCS does not directly contribute to the initiative, Lokad allocates enough time to make sure this person is ready to take over the initiative should the need ever arise. This practice largely mitigates complications related to unplanned leaves/turnover.

3. Roles, Responsibilities & Stakeholder Management

3.1 What level of cooperation do you have with the client company?

The level of cooperation we have with our clients varies, but overall it is much higher than that which is usually expected from an enterprise software vendor. Supply chain concerns are not equally important for all companies, therefore the collaboration tends to be stronger for companies where the supply chain is the (recognized) backbone of their activities.

The term ‘partner’ has been diluted to the point that even providers of trivial software products (such as time tracking software) end up being referred to as ‘partners’. However, after a year or two, most of our clients do refer to their relationship with Lokad as a ‘genuine’ partnership – in the true sense of the word. They have familiar faces at Lokad who have earned their trust and, consequently, those people – typically Supply Chain Scientists (SCSs) – are intimately familiar with their business. Moreover, our results are frequently deemed sufficiently notable to be personally presented to the CEO and/or company board, even in large companies.

The ongoing collaboration with Lokad allows our clients to positively re-engineer their entire supply chain practice. Ultimately, the whole chain is revamped, positively impacting both clients and suppliers. It should be noted that Lokad has no intention of replacing the critical strategic expertise that exists in the client company. Rather, Lokad wishes to automate the most mundane and repetitive aspect(s) of the supply chain decision-making processes. This approach subsequently frees up significant - and often scarce - client resources that can be redirected to better uses.

3.2 What roles and responsibilities do you expect to be in place, both within the client company and Lokad, to maximize the effectiveness of the solution?

There are 4 typical roles involved in Lokad’s quantitative supply chain initiatives.

The Supply Chain Leader: This role emphasizes the importance of top management’s involvement in the quantitative supply chain initiative. While not expected to delve into the technical details, this person must understand and communicate the strategic insights of the initiative. Their role is not to create metrics and KPIs, rather, their role is to critically assess and challenge them, ensuring alignment with the overarching strategy.
The Supply Chain Coordinator: Essential for ensuring the smooth operation of the initiative, this person acts as a bridge between various internal teams. Their primary responsibility is to gather feedback, communicate with stakeholders, and confirm/clarify processes and decisions. They ensure that the initiative aligns with existing company workflows, while also keeping an open mind to potential workflow revisions in the future.
The Data Officer: Data is the backbone of the quantitative supply chain initiative, and this person ensures its accessibility and reliability. Tasked with extracting comprehensive data sets (like sales and purchase histories), they are responsible for automating and scheduling data extraction. While their role is most intensive at the initiative’s outset, their contribution is crucial for its success.
The Supply Chain Scientist: This role merges insights from the Supply Chain Coordinator with data from the Data Officer to automate decision-making processes. Starting with data preparation, the Supply Chain Scientist collaborates closely with the Coordinator to clarify any data ambiguities. They then formalize strategies into actionable decisions, such as reorder quantities, and implement dashboards and KPIs for transparency and control.

See project roles for more information on the different designations within a quantitative supply chain initiative.

3.3 Do you have a complete RACI (Responsible / Accountable / Consulted / Informed) table for the implementation phase and for the production phase?

Yes. This information can be explicitly presented as a RACI table if it is deemed important by the client company.

More importantly, the Supply Chain Scientists (SCSs) internalize this sort of matrix in order to make adequate and rapid judgment calls as the initiative progresses. As far as issues related to the optimization of a supply chain are concerned, the crux is figuring out the best way to frame the problem. Following this, the focus shifts to identifying who in the organization is the best positioned to address the problem. Critically, all of this analysis has to be done quickly to preserve the momentum of the initiative.

Towards this end, Lokad’s SCSs are designated to spearhead the initiative, and to take ownership over the quality of the output generated by Lokad’s numerical recipe.

As such, it is a small nucleus of highly-trained specialists who are responsible for the supply chain decisions Lokad generates – rather than an elaborate “system” or “process” of delegating portions of responsibility between a large group of stakeholders. It is Lokad’s position that such systems tend to dilute responsibility, rather than rigidify it. Our SCSs are thus trained to adopt and operate with this responsibility, and that includes ensuring the relevant stakeholders at the client company are consulted and fully informed of the initiative.

3.4 Will you document roles and responsibilities using a RACI (Responsibility, Accountability, Consulted, and Informed) matrix for all stakeholders involved in the project? Will you ensure that this document is discussed and agreed upon by all involved parties?

Yes. All such elements (and more) are gathered and documented in the Joint Procedure Manual (JPM). The JPM is produced by Lokad’s Supply Chain Scientists (SCSs) (with insights collected directly from the client company). In this document, the parameters of each person’s role and responsibility is detailed.

The JPM also serves as an ongoing resource for the initiative and is written by the SCSs assigned to the client company. Producing this document in their own words demonstrates that the SCSs have taken considerable time to investigate, diagnose, and analyze the client’s supply chain and the overarching solution (without simply regurgitating the client’s preexisting literature).

Any revisions to the JPM are shared with the client company. The JPM itself is routinely discussed during work sessions between Lokad and the client company.

On a related note, our experience indicates that in the event disagreements do arise, they usually reflect an organizational issue to be resolved within the client company. This is why we recommend the client company appoints a Supply Chain Executive to supervise the initiative. One of their key contributions is to act as a go-between when such cases arise.

3.5 Will you ensure that the project working group and the steering groups are formed with named resources from the project stakeholders? Will you ensure that the operating rhythm is agreed upon by all parties involved?

Yes. As a general principle, we follow any process deemed necessary by - and formally agreed upon with - the client company. The elements agreed upon (and any changes made as the initiative progresses) are documented in the Joint Procedure Manual (JPM), which includes details regarding the project working group and steering groups. Through Lokad’s Supply Chain Scientists (SCSs), we have the necessary resources to install and monitor these processes.

Anecdotally, one of Lokad’s most frequently appreciated contributions is our ability to simplify processes – be they supply chain or bureaucratic in nature. Over time, we actively work to remove unnecessary bureaucratic layers from our client’s supply chains.

4. System Transition & Go-Live

4.1 What is the duration of transition from kick-off to go-live?

The typical duration for the onboarding phase is 6 months. This phase starts with the kick-off and ends with Lokad being ‘in production’ - that is, our automated supply chain recommendations effectively steering the client’s desired decision-making process(es).

This duration can be shortened by 1 month if a data lake is already in place – a well-constructed and documented data lake can shorten the onboarding phase even more. Conversely, this phase is typically increased 1 to 3 months when the client’s software or systems environment is unduly complex or outdated.

Interestingly, the complexity of the supply chain itself is not as impactful as it may seem, as Lokad strives to define a scope sufficiently precise that it is feasible within the intended timeframe. Our experience indicates that onboarding phases that last longer than 6 months put the initiative at risk of stagnation. Thus, we actively engineer the scope to mitigate this risk.

Such delays have little to do with the technical setup of Lokad itself. As a whole, the suggested timeline serves not only technical purposes (automating data extraction, testing numerical recipes, etc.), but also provides Lokad’s Supply Chain Scientists (SCSs) to become fully proficient with all the specifics of the client company, and for the supply chain teams to “digest” Lokad’s approach – something which typically represents a departure from the client’s legacy process.

4.2 How many visits on site do you plan? How many workshops on site do you plan?

The number of visits and workshops done onsite is negotiated as part of the specific contractual terms with the client company, though it should be noted that travel costs can affect the fees Lokad charges. Thus, the inclusion of onsite visits is ultimately a decision to be made by the client company, and Lokad will accommodate the desired frequency.

When the goal of the client company is to keep the initiative as lean as possible, we are comfortable with a fully remote initiative, i.e., no visits onsite. We recommend this approach for smaller companies (annual revenue less than 100M USD), and companies that are generally comfortable with remote contributors (like large eCommerce companies). About half of the initiatives carried out by Lokad belong to this category.

When the goal of the client company is to maximize the odds of successfully managing change, we are comfortable with visits every month - and possibly more frequently if necessary. For large companies (annual revenue above 1B USD), we recommend at least one quarterly visit/workshop onsite. This approach helps to develop company-wide alignment, especially when sizeable teams are involved.

For our clients in Western Europe, we tend to have more visits (typically lasting a single day) than workshops when we are onsite. For our clients outside Western Europe, we tend to do more workshops (typically lasting multiple days) than visits when we are onsite. This difference is a simple matter of associated travel costs and logistics.

4.3 What is an ideal balance between remote and onsite meetings?

For a quantitative supply chain initiative, the majority of meetings should be remote. Most meetings are short (30 minutes or shorter) and involve only two participants: a Supply Chain Scientist from Lokad, and a supply chain practitioner from the client company. Furthermore, remote meetings are beneficial for specific technical tasks, as all participants have access to their own computer setup, including access to large monitors. This is especially useful when the participants need to investigate complex reports.

However, Lokad does not underestimate the value of onsite meetings with clients. Onsite meetings often make it easier to convey complex ideas, discuss perspectives, and/or revise expectations between parties. Thus, we recommend adopting a regular rhythm for onsite meetings (e.g., weekly/monthly/quarterly…). Lokad treats such onsite meetings as significant events, particularly when Lokad hosts the client.

This approach allows both parties to keep remote meetings low-key, convenient, and as frequent as necessary.

4.4 Do you assist the client company in conducting a quality check of the production environment to assess readiness for go-live, including the setting up of interfaces?

Yes. In fact, Lokad goes beyond simply assisting the client company in its readiness assessment for a go-live. One of the prime responsibilities of Lokad’s Supply Chain Scientists (SCSs) is taking ownership of the end-to-end solution delivered to the client company. In other words, though a mechanized system (a fleet of machines) generates the results, it is still a person who takes personal responsibility for the system. They ensure the accuracy, relevance, and appropriacy of the end-to-end data processing pipeline – also factoring the client’s overall business concerns.

Given their error-prone nature, software interfaces deserve specific attention, and the SCS is well-equipped to assist in assessing their integrity. Lokad assesses this integrity on the ingress side (when Lokad gets historical data from the client company) and the egress side (when Lokad returns supply chain decisions to the client company). For this task, Lokad leverages specific methodologies and technologies.

Please see programming paradigms for supply chain to better understand the sort of technologies Lokad leverages to secure go-live readiness.

4.5 Do you prepare the production transition and migration strategy document to manage the seamless transition of business operations (from the existing business application to the new business application) for the client company?

Yes. The transition is documented in our Joint Procedure Manual (JPM). This extensive documentation, produced by Lokad’s Supply Chain Scientists (SCSs), ensures that both supply chain practitioners and supply chain executives have access to well-written materials that adequately explain the process in understandable terms. SCSs make notable efforts to ensure this document is accessible to a non-technical audience (although some annexes may be quite technical).

Also, Lokad’s dual-run approach is uniquely suited to ensure a smooth transition from the legacy process to the new solution. “Dual-run”, in this context, refers to the practice where Lokad will run concurrently with the legacy decision-making process over the entire scope of the initiative. The practice is only made possible due to the robotized nature of the legacy decision-making process by Lokad, ensures that the numerical recipes implemented by the SCSs of Lokad have been running satisfyingly in exact production conditions, over the entire scope, for weeks prior to the actual go-live, where Lokad’s decisions supersede the legacy process.

It must be noted that such dual-run is typically not possible with alternative technologies and methodologies as proposed by our competitors. Indeed, as they do not robotize the supply chain decisions, the overheads associated with a dual-run are significant. As a result, the dual-run is, at best, performed over a small scope that does not genuinely reflect production conditions. As a result, when such an approach is adopted, the late extension of the scope invariably leads to production incidents that would have been entirely preventable with a full-scope dual-run.

4.6 Do you provide the scope, timelines, and success criteria for the pilot run to be reviewed and signed off by the client company?

Yes. The scope is always detailed in the contractual agreement between Lokad and the client company. It usually takes the form of a given type of supply chain decision (e.g., inventory replenishment or stock allocation) over a set of locations and/or over a set of business systems.

The timeline is typically under 6 months (from kick-off to production). While a projected timeline is always included in our commercial proposal, it might not be specified in the contractual agreement. The binding timeline represents a mutual commitment, and the pace of the Lokad initiative depends on the timely execution of certain steps by the client company, notably the construction of a data pipeline to Lokad.

In terms of success criteria, the decision is always made unilaterally by the client company. While we can document the guiding principles that should support this decision, a non-unilateral decision would be unusual. Simply put, a vendor should not be in any position to decide that the pilot was a success if the client thinks otherwise.

Please consult Assessing the Success of a Quantitative Supply Chain Initiative for more on this nuanced point.

4.7 Will you organize the conduct of pilot runs to ensure a) data adequacy, b) system configuration and application readiness, c) process/system compliance, and d) overall fit-for-purpose?

Yes. As a rule of thumb, we treat a pilot – intended to deliver supply chain optimization – exactly like we would treat a ‘real’ initiative intended to be brought to production. For all intents and purposes, as far as supply chain optimization is concerned, an adequate pilot is indistinguishable from a pre-production setup that is approved for production use.

Lokad’s team of Supply Chain Scientists (SCSs) is responsible for all of the above. In our experience, data adequacy is rarely an issue in companies that went digital many years (if not decades) ago. As long as there is a business system to track what is bought, produced, stocked, and sold, the initiative is nearly guaranteed to have adequate data. The challenge is making sense of the data that was not originally collected to support the optimization of the supply chain.

See bad data for more information on this point.

5. Change & Risk Management

5.1 What support can you offer to the client company to help manage the change management associated with implementing the initiative?

All clients have the full commitment of Lokad’s Supply Chain Scientists (SCSs), all of whom are trained to handle the technical and non-technical requirements of a supply chain optimization initiative. The SCSs assist in the change management process in numerous ways, including:

Proposing improvements to existing processes for the supply chain practitioners employed by the client company.
Producing training materials to onboard members/teams of the client company.
Assisting the supply chain management by quantifying in Dollars or Euros (or the currency of the client’s choice) the impact of the changes brought to the supply chain.

It must be noted that change management can represent a significant time commitment for an SCS. While each SCS has uniquely suitable skills and experience in helping supply chain leadership in change management, this duty competes with all their other duties.

Thus, the contractual terms negotiated between Lokad and every client specify the amount of resources - i.e., the sizing of the team of SCSs - that will be available to support the initiative. Our commercial proposals usually anticipate that SCSs will provide some change management support. However, our proposals do not usually reflect any kind of “large-scale” support for change management - unless this is explicitly requested by the client.

5.2 During the production phase, what is your vision for the change management? What are the main milestones? What does the new organization look like after the successful implementation of the new solution?

Once Lokad is in production, an entire class of supply chain decisions is automated. The goal is then to turn the supply chain practice into a capitalistic undertaking. Every hour spent by a supply chain practitioner should contribute to the ongoing improvement of the numerical recipes. This is a departure from the ‘mainstream’ supply chain practice where the vast majority of efforts on any given day are allocated to keeping the company in business for one more day. Naturally, the transition to this value-adding form of supply chain is gradual.

The first milestone is to get the supply chain practitioners to acknowledge that Lokad allows them to discard most of the legacy process. For example, it makes sense to review daily replenishment quantities when those quantities are frequently incorrect. However, by design, Lokad’s quantities are already sound and do not need further review. As a matter of fact, 0% nonsense in the figures Lokad generates is the primary criterion for a production go-live. The trust supply chain practitioners can place in Lokad’s figures naturally frees up lots of time that can be put to better use.
The second milestone consists of having a few “early adopters” among the supply chain practitioners. These are typically people who quickly manage to separate from the non-value-adding legacy process - e.g., manually reviewing figures - in order to focus on the continuous improvement of the supply chain through its numerical recipes. They can start tackling numerous important questions beyond just minor technical aspects (for example, is the client company looking at its quality of service from the right perspective?).
The third milestone is to have the bulk of the supply chain practitioners looking outward (clients and suppliers) rather than inward. Ultimately, the supply chain must deliver an alignment that goes beyond the boundaries of the client company. This expands the pool of collected insights and helps to further refine the numerical recipes.

The new organization is much closer to a software company. There are few repetitive supply chain tasks that are manually handled - as repetitive tasks are now automated. There are also much fewer emergencies (again, due to automation). The reduction of routine tasks carries an increase in task variety for the supply chain practitioner. Typically, this translates into less time and effort dedicated to controlling the supply chain, but more is expected from management to upskill employees so they can capitalize on the increased disposable time and effort.

See (Software) Product-oriented Delivery for Supply Chain for more on this transition.

5.3 How do you handle workflow change for end users? First, with the Lokad onboarding, second with Lokad’s own evolution.

By design, the supply chain decisions generated by Lokad do not require workflows. In fact, automating all steps involved in generating the supply chain decisions is the desired arrangement.

However, if explicitly requested by the client, Lokad is capable of introducing a “workflow” that mirrors the legacy one. This, it must be understood, is purely to facilitate change management, and is not a requirement for the success of the numerical recipe in any way. As client employees become more familiar with - and develop greater trust in - the decisions Lokad generates, the “workflow” can be gradually simplified, until such time that it is completely removed.

Regarding Lokad’s evolution, our platform is programmatic and managed by Envision (our domain-specific programming language). Any changes/updates to Envision is done through automated scripts, and this process is programmed in such a way that the supply chain initiatives Lokad hosts are untouched.

5.4 Can you maintain an Issues & Risk register that includes a mitigation plan, tasks, accountabilities, timelines, and status (not started, in-progress, closed, on-hold)? Will Lokad’s Project Manager be responsible for tracking all Issues & Risks and ensuring timely resolutions or managing escalations when necessary?

Yes. Lokad’s platform comes with its own internal issue/ticket/task manager. This function provides all the usual capabilities that are commonly expected from such a tool, such as managing statuses, priorities, assignments, notifications, etc. Moreover, we separately maintain a Joint Procedure Manual (JPM) that provides a comprehensive and well-organized presentation of the initiative with all the relevant high-level timelines. Lokad’s Supply Chain Scientists (SCSs) are responsible for the supervision of the task manager. They make sure that issues and concerns are addressed promptly.

Escalations are possible but rare. The same SCS who manages/reviews the tasks will also resolve them. Senior SCSs at Lokad fulfill a wide range of roles: supply chain expert, data engineer, data integrator, business analyst, data scientist, project manager, change consultant, etc.

The ability to easily contact SCSs is something our clients routinely cite as a major positive. The client can immediately interact with the person whose job is to oversee the satisfactory resolution of any issues rather than have to navigate several layers of bureaucracy in order to - hopefully - speak to someone capable of helping them.

In the event there is a problem requiring skills outside the expertise of an SCS (e.g., a technical issue with the platform’s architecture), they still supervise the timely resolution of the problem and act as the first point of contact for the respective client.

5.5 Do you offer organizational change management consulting to address the introduction and modification of business processes, as well as the decommissioning of existing processes?

Yes, if the client company wishes their partnership with Lokad to include change management consulting services. It should be noted that Lokad’s primary expertise lies in the predictive optimization of supply chain and not change management. Our approach to change management is also more conventional than our supply chain practices. This approach, if implemented, would limit the amount of third-parties involved in the project.

Alternatively, if the client company prefers to retain the services of a change management specialist to supplement Lokad, we will support them by sharing as much as the client company deems prudent.

6. Customization & System Functionality

6.1 Do you arrange sessions to prioritize customization requirements, ensuring an understanding of business impacts due to product gaps and reaching a mutual agreement on the priority for releasing customizations?

Yes. Lokad’s Supply Chain Scientists (SCSs) are in charge of this process. In fact, Lokad stands out on two fronts as far as this prioritization is concerned. First, an SCS is capable of independently implementing the customization and, thus, is capable of providing clear insights into what is at stake in terms of resources and timeline.

This greatly improves the quality of the prioritization, as the client company benefits from an expert who can readily balance the benefits of any given supply chain change with the costs associated with this change.

Second, ‘Quantitative Supply Chain’ - Lokad’s overarching philosophy - emphasizes a purely financial perspective. Hence, the SCS supports the client company in providing quantitative estimates (in dollars or euros) of the impact of a potential change to be brought to the solution. This strategy refines the initiative by avoiding the traditional bottleneck of debating what should be prioritized. Instead, Lokad streamlines this process by prioritizing issues that result in the greatest financial impact.

6.2 Can you conduct a fit-gap study of all business processes to identify automation opportunities, document the desired future processes, and determine gaps in product functionality? Can you suggest acceptable work-arounds when product functionality gaps are identified?

Yes. Lokad’s Supply Chain Scientists (SCSs) are in charge of this process. While an initial study will be conducted at the start of the initiative, this process in ongoing throughout the production phase. It is part of our approach to pursue continuous improvements of the solution.

As far supply chain optimization is concerned, gaps are rarely a matter of ‘functionality’, but rather a matter of ‘performance’. For example, the challenge is not only to generate replenishment quantities (functionality) but to ensure the quantities generated are the most profitable ones (performance).

Thus, SCSs are concerned with identifying and addressing ‘performance gaps’, which sometimes require additional functionality or re-engineering of the solution. This can involve adding or removing features to optimize overall performance.

On a related note, Lokad’s platform is programmatic. Thus, any perceived ‘functionality gaps’ can be addressed by introducing (or tweaking) a few lines of Envision code. This programmability is precisely what allows Lokad to provide tailor-made solutions to each client.

6.3 Can you provide a detailed agenda for the process fit-gap analysis workshops, including the SME (Subject Matter Expert) expectations from the client side, at least one week before the workshops begin?

Yes. Lokad’s Supply Chain Scientists (SCSs) provide an agenda for every workshop. We ensure the agenda is communicated at least one week before the event. If explicit instructions are given by the client company, such as a timeline to provide the agenda(s), then we will follow them. In the absence of instructions, we will structure workshops (including timeline and conveying all necessary steps client-side) in an intelligent and professional manner.

6.4 Do you ensure that the product customization requirement documents are jointly reviewed and approved by the client company?

Yes, these documents will be provided to – and subsequently approved by – the client company.

Please note that Lokad’s platform design choices largely eliminate the need for ‘customization’ - at least how this term is commonly understood in enterprise software circles. Lokad’s platform is programmatic, utilizing Envision - our DSL (domain-specific programming language) dedicated to the predictive optimization of supply chain.

Thus, Lokad’s solutions are always ‘customized’ in the sense that they are fully tailored to the specific needs of the client company. However, such customization is delivered in a way that keeps the solution part of Lokad’s main product line. This is Lokad’s preferred (and deliberately engineered) approach, and does not present any maintainability issues.

6.5 Do you assist the client company in establishing interface connectivity with external systems, and in testing and certifying the interfaces?

Yes. Lokad’s Supply Chain Scientists (SCSs) provide support to set up, test, validate, and document the interfaces between the systems operated by the client company and Lokad. The SCSs might be supplemented by some internal IT resources at Lokad for the very low-level technical aspects, such as networking or security protocols.

The system interfaces are typically not ‘certified’ by a third-party certification body. The interfaces are ‘formally specified’ through technical specifications jointly agreed upon between the client company’s IT department and Lokad. This technical specifications support the companies’ mutual obligations: in short, the client company commits to providing the required data to Lokad on time; Lokad, in turn, commits to returning results on time as well.

6.6 Do you provide interface specification documents during the workshops, including sample messages?

Yes, Lokad provides interface specifications during workshops. Sample messages can be included if desired by the client company.

Given the nature of Lokad’s service, though, the “sample messages” will very likely take the form of tables - as this more accurately represents the output Lokad generates for the client. For reference, the vast majority of the technical specifications for the interfaces will focus on tables and their format(s), as well as table extraction patterns and transfer schedules.

Yes. Lokad’s Supply Chain Scientists (SCSs) are in charge of this process. It is important to note that Lokad has two levels of changes and releases, which is different from typical enterprise software.

Firstly, changes made specifically for clients are implemented by the SCSs themselves. These changes occur frequently, often multiple times per day, particularly during the onboarding phase. Such changes are in direct response to the client company’s needs and involve considerable communication between both parties.

Secondly, we make updates to Lokad’s platform, typically through updates to Envision - our DSL (domain-specific programming language) dedicated to the predictive optimization of supply chain. These changes are designed to be transparent for the client companies. If desired, the details about these updates can be provided, and much of this information is made publicly available.

See Envision VM Environment and General Architecture for further information on the evolution of Lokad’s platform.

7. User Acceptance Testing (UAT)

7.1 Do you assist the client company in setting up the UAT (User Acceptance Testing) test environment with context specific data and system configurations?

Yes. Lokad’s Supply Chain Scientists (SCSs) are in charge of this process. Lokad offers unique methodological and technical innovations in support of this.

In terms of methodology, we favor the design of prioritized lists, where items are ranked by decreasing return on investment (ROI) for the company. This aspect is critical to ensure the end-users’ time is not wasted reviewing large amounts of largely irrelevant data.

In terms of technology, Lokad’s platform has been specifically engineered to concurrently support multiple environments for any given initiative. These environments are a native feature of our multi-tenant SaaS platform, and thus can be introduced with minimal overhead, both in terms of compute resources and system administration time.

7.2 Do you configure the UAT (User Acceptance Testing) pre-production, production, and training environments according to the defined ToBe processes?

Yes. Given the rich programmability of Lokad’s platform, we can exercise full control over configurations. This is made possible through Envision - our DSL (domain-specific programming language) dedicated to the predictive optimization of supply chains.

This approach allows different environments to use the same configuration for all parts that are not subject to change – by using the same code wherever possible. This greatly reduces accidental differences between environments, which can confuse users and compromise UAT process integrity.

Furthermore, advancing a setup from one stage to another is straightforward with our design. Using a codebase for configuration changes is more efficient than traditional user interface methods.

7.3 Do you provide separate UAT (User Acceptance Testing), data migration, production stage (pre-prod), production, and training environments for the product (including the required interfaces) to the client company and external systems?

Yes. Lokad’s platform has been specifically engineered to concurrently support multiple environments for any given initiative. These environments are a native feature of our multi-tenant SaaS platform, and thus can be introduced with minimal overhead, both in terms of compute resources and system administration time.

With Lokad, duplicating the entire production environment, including all the production data, is done without doubling the data storage footprint. Internally, data that is identical between the two environments is mutualized. Moreover, our constant-time design ensures that the workload from one environment does not negatively affect the performance of another environment.

However, most enterprise software vendors bypass the whole issue by just ‘cloning’ the main setup. Cloning - or straight duplication - is easy but wasteful. Cloning means that the amount of resources (people and machine) increases linearly with the number of environments — e.g., three environments triple the original costs. For any sizeable supply chain, this translates into sizeable costs.

7.4 Do you guarantee the timely resolution of all defects to ensure that UAT (User Acceptance Testing) is completed within the mutually agreed-upon timeline(s)?

Yes, provided nuanced definitions of ‘resolution’ and ‘defect’ can be agreed upon. Overall, Lokad’s Supply Chain Scientists (SCSs) are in charge of resolving all issues that undermine the initiative’s core goal: increasing return on investment. In a typical scenario, the SCS proposes an appropriate action and a corresponding timeline, which the client company validates or updates at their discretion.

It is critical to highlight that when it comes to supply chain, there are no perfect solutions, only better and worse tradeoffs. In other words, one cannot really solve a problem where two or more values are in complete opposition.

For example, expired perishable inventory is wasteful, but when handling perishable products, such waste cannot be completely eliminated without creating a consequent quality of service issue. A balance has to be found between dead stock and stockouts. Yet, both ‘dead stock’ and ‘stockouts’ are defects in a sense.

In short, SCSs can resolve ‘mundane’ problems as they arise, such as fixing a parsing error when reading a file (a software bug). However, the overarching goal of a quantitative supply chain solution is not to “solve problems” but to increase return on investment (in dollars or euros). Lokad achieves this brand of “resolution” through an intelligent, financially-driven approach to supply chain tradeoffs.

7.5 Do you assist the client company in reviewing the UAT (User Acceptance Testing) scenarios, test cases, and test data?

Yes. Lokad’s Supply Chain Scientists (SCSs) are in charge of this process.

However, as far as supply chain optimization is concerned, datasets smaller than the entire production setup are generally not sufficient. In practice, scenarios, test cases, and test data must be (nearly) as large as the production setup to reflect an end-to-end supply chain perspective. This requirement has nothing to do with Lokad; it is just the nature of supply chain.

7.6 Do you guarantee onsite support at the client company headquarters during the UAT (User Acceptance Testing) phase?

Yes. Onsite support is governed by the contractual agreement between Lokad and the client company. This aspect is always negotiated on a per-client basis.

It should be noted that a quantitative supply chain initiative with Lokad features continuous supply chain improvement, hence there is no fixed UAT period. Testing typically starts at the end of second month, peaks by the fourth month, then stabilizes by the sixth month onward.

By dedicating ongoing resources to the refinement of our numerical recipes (algorithms dedicated to optimizing supply chain), Lokad ensures each client has an up-to-date initiative.

8. Post-Implementation Support & Auditing

8.1 Can you ensure that the observations from the pilot runs are documented, and any action items are assigned to concerned stakeholders across the client company’s Technical, IT, and Supplier departments, and also tracked to closure?

Yes. Lokad’s Supply Chain Scientists (SCSs) create and maintain a Joint Procedure Manual (JPM) for each initiative. It includes all pertinent insights for the initiative. Importantly, the JPM is designed to be accessible to non-technical audiences (although some sections and annexes are quite technical).

High-level action items are documented in the JPM. However, minor action items are typically handled with the task manager on Lokad’s platform. These minor items are short-lived and the task manager facilitates tracking and closing them better than the JPM.

8.2 Can you ensure that sufficient quality and compliance reports are available to monitor usage and adoption of the system?

Yes. Lokad’s Supply Chain Scientists (SCSs) typically implement dedicated instrumentation for this purpose during the final stage of onboarding, just before the official kick-off.

Additionally, Lokad can track the alignment between supply chain decisions it generates and the actual decisions made in the supply chain. This is done to identify potential sources of divergence, such as bugs or glitches in the client’s systems, that might affect the implementation of Lokad’s recommendations.

8.3 Will you conduct an annual audit of the application and provide feedback on improving usage and end user adoption of the system, in order to realize ROI (return on investment) faster?

Yes, a yearly audit of the entire solution (end-to-end) is standard operating procedure. That said, Lokad’s Supply Chain Scientists (SCSs) typically audit the whole solution several times throughout the year. The yearly audit usually leads to a detailed roadmap presentation for the client’s leadership. This is in line with our approach of continuous improvement for each initiative.

Regarding usage, in practice, SCSs proactively implement dedicated tools early on to monitor usage, adoption, and compliance with the supply chain decisions Lokad generates. While a yearly audit presents an excellent opportunity to make necessary adjustments, our SCSs are very proactive when it comes to the adoption of Lokad’s supply chain recommendations. This matter will be discussed during our weekly work sessions, as the adoption of Lokad’s recommendations is the primary driver of increased ROI in a quantitative supply chain initiative.

8.4 Can you ensure that the dedicated product support team, based on site at the client company headquarters, continues to support the product for at least 6 months post go-live?

Yes. Lokad’s team of Supply Chain Scientists (SCSs) take care of this task. Our SCSs are amply trained to both continuously improve the initiative and provide ongoing support to the client. The continuous onsite presence of SCSs will be negotiated and clarified in the contractual agreement with the client, if this is something the client wishes to pursue.

On a related note, Lokad strongly recommends maintaining an active, ongoing commitment to the improvement of the solution, particularly client-side. Phasing out continuous improvement efforts will, in our experience, undermine the strength of the initiative. Any changes client-side, including modest tweaks in the applicative landscape or constraints, can impact the quality of decisions generated by Lokad, hence active vigilance and ongoing improvement are advised.

9. Incident & Defect Management

9.1 Can you ensure that all must-have defects and change requests (critical and high-priority items) are taken up as a priority and delivered, in order to avoid any delays in the client company’s go-live timeline(s)?

Yes. Lokad’s Supply Chain Scientists (SCSs) are in charge of this process. Our platform is designed in such a way that enables them to address defects and change requests in a swift and autonomous manner.

Lokad’s platform is programmatic, which is made possible through Envision - our DSL (domain-specific programming language) dedicated to the predictive optimization of supply chains. This programmability means SCSs can promptly deliver fixes and implement requested changes to the initiative, and to a level of precision not commonly found in enterprise software.

Beyond technology, Lokad’s SCSs are trained to fulfill a number of key roles, which naturally reduces the number of people needed to address defects and change requests. These roles include supply chain expert, business analyst, data scientist, data engineer, and system integrator. They are thus well trained to provide fixes and updates while also maintaining the client’s main priorities in mind.

9.2 Can you implement a defect monitoring mechanism to ensure timely closure of all defects and usability issues?

Yes, the Lokad platform comes with its own task / ticket / issue management system. Those capabilities give us the capacity to precisely follow the timely resolution of the issues. Those resolutions are taken care of by the teams of Supply Chain Scientists (SCSs) employed by Lokad.

However, it’s important to not lump together “defects” and “usability issues. For example, an inaccurate demand forecast is a “defect”. It’s negatively impacting the supply chain. However, depending on the market conditions in which the client company operates, this “defect” may never be fixed, only mitigated. When it comes to the predictive optimization of supply chains, solutions are always trade-off, resolving a defect, creating another defect (hopefully a smaller one).

In contrast, usability issues are typically straightforward to address. Thus, for this class of issues, we are willing and committed to ensure a timely resolution, as addressing the issue does not, typically, create any other issue.

9.3 Can you ensure that defects encountered during testing of releases (prior to production) will be attended to and rectified in a timely manner, so that they do not impact the client company’s timeline for the go-live of the release?

Yes. If the identified defects concern the client-specific codebase (written in Envision), then the defects will be rectified by Lokad’s Supply Chain Scientists (SCSs). If the identified defects concern Lokad’s platform, then the defects will be rectified by Lokad’s software engineering teams.

In either case, Lokad’s release process involves extensive testing in order to make sure that defects are identified and fixed prior to the release (go-live).

9.4 How will you address incidents that may be raised by the client company through any of the following channels: telephone, email, office communicator, and/or direct entry into the Incident Management Tool?

Supply Chain Scientists (SCSs) treat all incident reports - regardless of how they are sourced - with maximal seriousness. The contractual agreement between Lokad and the client company will specify how many SCSs will be assigned to the project, as well as the hours per week the client can expect direct support to be available.

The resolution of a typical incident begins with an SCS creating a new entry in the task/ticket/issue manager. This ensures there is a traceability for the incident.

Next, the SCS will diagnose the problem. If the problem needs a fix on Lokad’s side, the SCS will immediately mobilize the necessary resources to solve the issue - typically the SCS himself/herself.

Finally, once the issue is addressed, the SCS will assess the true root cause for the issue being reported, even if the report was finally diagnosed as a non-issue. Usually, there is an underlying issue somewhere that needs to be addressed. By addressing the deeper root cause, Lokad proactively eliminates similar issues in the future.

9.5 If a defect is reported outside the Incident Management Tool – through another channel such as email - will you register the defect in the tool as soon as it is raised for proper tracking and compliance?

Yes. It is standard practice to create a corresponding entry within the Lokad platform when we receive a report through a channel other than the task / ticket / issue manager. This practice facilitates thorough tracking and compliance.