As you may gather from other parts of the site, we think Sabisu’s architecture is innovative and exciting. By splitting functions between an on-premise server and cloud server we get some important advantages:
- Security – all enterprise data remains within the enterprise firewall unless access is specifically and explicitly given.
- Flexibility – applications can be deployed to the cloud or on-premise as required yet retain a consistent user experience.
- Speed – because we aggregate huge amounts of data on the on-premise server, it means we can deliver a much-reduced dataset to where it needs to go, so we get great speed over any given bandwidth
We’re particularly fond of the Sabisu architecture because of what it allows us to do and a great example is with Capital Projects.
The normal run of things is that these projects have a supply-chain attached as they’re contracted out to an EPC, who then uses vendors to deliver key products, themselves using sub-vendors. Yet these projects are often part of a mega-project, defined as a collection of projects which total over $1bn+, so there are many layers involved:
Each of these layers has layers within it; account managers, engineers, technicians, finance people and so on. It’s a large, complex supply-chain, made more so by the fact that many projects can be using the same vendors and sub-vendors. It’s not unusual to have conflicts of interest between projects.
Even without this complexity there’s an obvious problem; when something occurs at the bottom of the chain, it’s a long way from the people who are funding the project. By the time the top of the chain has an appreciation for the impact of a sub-vendor issue, it’s too late to mitigate it’s effects. Typically these are large engineering projects where reporting is completed monthly, meaning the funding boards are at best 4 weeks from dealing with an issue occurring right now – at worst, months away. The impact also increases as you travel up the supply-chain (‘the Bullwhip effect’) so a minor sub-vendor issue can cause a huge project impact.
We can change this. Here’s how we’re going to do it.
We’re proposing we put a Sabisu on-premise server into the EPC and Vendor layers. (We’ll leave the others for now). This will interface with EPC and Vendor systems to bring their data out to the Client layer in real-time, so that the people funding the project can see progress in real-time. The project just became genuinely transparent. No more waiting to be told there’s a problem; it’s a shared project environment for solving problems as a team.
From there it’s a simple matter of choosing the trends and spot values that those at the top who fund the mega-projects need to see. As the on-premise server is building a history of the project as it evolves, it’s entirely feasible to invent new KPI measures half-way through and have the data to hand.
We think we can improve three key capabilities:
- Decision quality and speed; with all the data coming from a single source, you have one version of the truth. The project is able to influence situations as they develop allowing costs and schedules to be protected.
- Situational awareness; simply put, transparency means genuine situational awareness so the bullwhip effect can be mitigated, preventing a single problem becoming a latent crisis.
- Efficiency; having a single place where the multiple layers of a global supply-chain can work collaboratively with the data represents a step-change in project efficiency, eliminating lengthy communication chains and allowing everyone at every level to get what they need.
We know you’ll be impressed and look forward to seeing you on there.