Lab0 is the AI forward deployed engineer for enterprise software to go live faster

Why enterprise? Why software? Why is it slow? Why does it need to be faster?

What is enterprise software? Enterprise software is software that’s sold to enterprises. So a simple saas product could also be an enterprise software.

Why is deploying enterprise sw slow?

Enterprise data lives in several different data sources.

Across different platforms (SAP, salesforce, oracle, servicenow, GCP), different versions of a platform (SN Australia, SN zurich), documents live away from data (confluence, drive), communication lives away from documents (slack, email, teams) and a majority of workflows are not documented and live inside peoples’ heads (tribal knowledge). Before deploying a new product at an enterprise, we first need to do an inventory of the existing data and processes. This is a long process that we call discovery- this could take from a few weeks to a few months.

Once we have visibility into what exists and how things are run presently in the company, we can proceed with the next step - painting a picture of how things will look like after “implementing” the new software- the to-be process. But a to-be map alone is not sufficient, there needs to be a plan of how that ideal state will be achieved, how long will it take and how much will it cost. Some people call this change management.

A big problem that comes with change management is pushing the poeple to change. People hate change by nature and thus this step in the chain becomes a highly time consuming, political, alignment exercise between stakeholders- again, timelines are in months.

Once the stakeholders are aligned, there’s buy in on the plan, the data and processes have been mapped out, we can proceed with the real meat of the implementation. Implementation begins with a design - A fairly detailed technical description of what the solution will look like, how it will integrate with existing platforms, what workflows it’ll support, how each of those workflows will be configured, what new tables and fields in those tables will be created. The granularity of the plan could vary, this could be high level or down to the exact API endpoints that will be connected.

Sometimes this plan is laid out all at once in the beginning (waterfall) or it happens in phases with every phase having a concrete deliverable (agile).

This could be anywhere from 60% out of the box (ootb) to 95% ootb, meaning all you have to do is configure the product, but there’s always some element of custom development present. This could be creating an endpoint to connect to an internal service or writing some code to configure the platform to work a certain way. Traditionally, people have relied on system integrators like KPMG & Accenture to do these kinds of integrations due to their rich SME workforce - eg someone like an EY would have a few experts who understand the nuances of a particular config in a 7 year old servicenow release, which the enteprise is running. Beyond this is the usual SDLC - UAT, CI/CD -> build ->repeat

So coming back to the question, why is this slow? It is slow because of 3 major reasons -

  1. context scattered across databases, communication channels, documents and peoples’ heads
  2. sub-par planning - it’s impossible to preempt the exact implementation plan down to the T with incomplete information
  3. human executors - the weakest link in the chain. Humans are inefficient, lazy, political and err quite often.