Not only business-to-consumer (B2C) has experienced or are experiencing the digital transformation, but the internal supply chain management sector is feeling it as well. This in turn has a big impact on all the components of the supply chain cycle.
This was no different at ENGIE Fabricom’s Operation Support Services (OSS). They reached out to Digital Innovation to build an integrated, automated, and digital solution. They primarily used email, telephone, or fax for requesting a new order and the delivery process that followed upon it. This situation created numerous questions, but mainly, “Is there a tool to keep track of everything?” It seemed then that the tools (and data) were there, but the orchestration between them was missing some key points, and some instruments needed to be replaced to make it sound better. The solution: Provide those instruments.
The analysis consisted of sketching the current workflow and defining the wanted outcome in detail.
Develop a single channel solution in the form of a platform for the user, where all tasks could be completed which were previously done through email, telephone, and fax.
Create/deploy a back-end framework that is flexible enough to handle all the different kinds of orders and is also capable of handling future changes, considering the constant evolution in supply chain management.
For now we will focus on the front-end.
After the analysis part to figure out what the desired outcome was we did some inventory on what was already there. What we immediately saw was a Microsoft oriented landscape. This was perfect considering Digital Innovation already has the required experience using this stack.
After some considerations we decided to use the web application framework C# ASP.NET MVC 5 to create the front-end. Bizagi would be the used framework to handle the orders coming in from the platform.
Because there were a lot of restrictions for accessing the on-premise resources and servers, we used Microsoft's cloud computing service Azure to deliver fast and reliable testable releases in the development phase.
This brings us to the manner in which we developed the product and tested it. As for many projects we used the Agile Workflow using JIRA and Confluence software by Atlassian. We would release a new version of the product every four weeks, after which ENGIE Fabricom’s OSS were able to test the product and log any bugs or new requirements directly in JIRA, which made the project management easy.
In this project we encountered a lot of challenges concerning data. One of these was the amount of products we had to work with and where the data came from. After developing for a couple of months, the data model we accomplished became rather complex. A product model for example: We had a product, which had a product translation, which in turn had characteristics (properties), stock, and content (where content could be an image or a document as well, where a document would have different translations). In total we had to deal with 70,000 products which all were as complex as the example just given. You can probably imagine that when you want to show all products to a user, or want the user to be able to search in these products, the application responsiveness can easily suffer the consequences. So we build a two-way solution to deal with this problem, because it actually consisted of two parts.
We cached every call a user made. So if user “X” wanted to view all products, all that was necessary concerning getting data, building views et cetera was saved. If user “Y” wanted to view all products as well, the system recognized it and only loaded the previously generated result. This gives a time gain of three seconds versus the previous eight seconds. Of course three seconds was still too long. This brings us to the second solution we implemented.
Indexation. We knew that every view of a product, being a search or an overview only needed a couple of fields from the product and therefore we generated a “Indexed_Products” table, which only included fields that were needed for searching or building a product page. After this we went from three to 0.1 seconds!
One final challenge we had to overcome was the data source origin.
This challenge also consisted of a couple components
The data we needed was not in the same structure as was needed for the Catalog. So we needed to transform each result into Catalog Models.
There was no possibility connecting to a SQL server directly but only through http(s) because of security policies.
The data we needed was partially coming from the ENGIE Fabricom Department, but we needed live data from ENGIE Datacenter as well (SAP).
Solution: We built an on-premise API which gets data from the department, but was also capable of getting real time data from SAP where needed. After this we built an API for the Catalog on the DMZ, which could talk with the Department API to get and transform data. This way future applications build by the department can use the Department API, which returns raw “OSS Data” and can serve as a general data provider (reusable), but can also be extended to implement more data sources. The Catalog API uses the Department API but “acts” as the Catalog infrastructure layer.
Within six months Digital Innovation accomplished to build a customer-friendly digital self-service suite. It is fast, highly flexible, and resulted in a big increase concerning efficiency for ENGIE Fabricom’s Operation Support Services. The main thing we want to highlight is that no matter how complex your current organisation infrastructure is, or what problems are on the surface right now, we can find the perfect solution for your situation.