Wednesday, April 25, 2018

What to Look Out for When Evaluating Low-Code Development Platform?

As described on Wikipedia:
Low-code development platforms (LCDPs) allow the creation of application software through graphical user interfaces and configuration instead of traditional procedural computer programming. The platforms may focus on design and development of databases, business processes, or user interfaces such as web applications. Such platforms may produce entirely operational applications, or require or allow minimal coding to extend the applications functionality or for uncommon situations. Low-code development platforms reduce the amount of traditional hand-coding, enabling accelerated delivery of business applications. A common benefit is that a wider-range of people can contribute to the application’s development, not only those with more formal programming experience. LCDPs also lower the initial cost of setup, training, and deployment.
Low-code development platforms employ visual, declarative techniques, which define data, logic, flows, forms and other application artifacts, without writing code, according to Forrester Research. Imagine Lego blocks for software application development. Developers may code to integrate access to older applications, for reporting, and to customize for special user interface (UI) requirements, Forrester analyst John Rhymer wrote in an October 2017 research report.

Why is There a Shift from Traditional Coding to Low-Code?

Low-code development platform has been gaining widespread tractions from enterprises worldwide to tackle challenges witnessed in traditional coding with programming languages.

1. Difficult to meet desired timeline complementing go-to-market strategy:
Every business unit is crafting its digitization needs and roadmap, yet, time is a fixed constraint. It is challenging to have speedy go-to-market products with traditional coding. Proof-of-concept (POC) with minimal viable product (MVP) is often taking more time than justifiable.

2. Lack of agility:
Change is inevitable in business, so embrace it. The lack of configuration tools for form and process flow changes is making it challenging for programmers to adapt with business rule changes, as it often leads to longer development time and to some extends, unmanaged scope-creep.

3. High long term maintenance costs:
Compared with changes through configuration, an application system developed from coding with programming languages and frameworks will require development continuity and support by qualified and experienced full-stack software engineers. Knowledge and technology transfer from application creator to another person will also require prerequisites for extensive programming competency. Thus, the long-term maintenance cost of such application system also includes the costs associated with talent retention. Otherwise, when maintainability falls-out, the application system eventually suffers along with higher technical debts.

4. Poor quality:
When every feature is developed from coding, a commonly used user interface component such as pagination table with search filters could also present programmatic bug.

Sunday, April 8, 2018

3 Reason to Further Modernize ERP System with Process Digitization

In manufacturing, distribution and trading industries, ERP (Enterprise Resource Planning) system is undoubtedly a core and impactful system to have in place. ERP system has been modernizing these industries for decades before the terms "digital transformation" and "digitization" were made popular.

Today, as workforce is generally getting more IT-literate and mobile-ready across most job functions, ERP system alone is no longer the magic wand to modernize IT in manufacturing, distribution and trading businesses. More gaps are surfacing itself from ERP digitization needs.

1. Control the process/SOP that occurs before data goes into ERP software

In many companies (even the global MNCs), the process that governs how data is approved before it goes into ERP is not automated. Take a simple example - Customer Master Data Change Request. Let's say a sales manager files a request to adjust credit term for a customer account. Yes, surely, the credit term setting is supported in ERP as part of customer master data. But when there is a change request, often, ERP is not the place where change request approval process is automated. So, sales manager in this case, would fill up an Excel spreadsheet or Word document, then send it out as email to the relevant approvers based on stipulated SOP (standard operating procedure). Once approved, let's say by the Regional Sales Head, the spreadsheet/document then goes to Finance Department as email attachment. Email message is not exactly known as the most reliable method for approval task tracking.

For a MNC with worldwide business presence, this kind of change request happens every single day. Yet, hardly automated. And there are many other similar examples, such as vendor master data change request, periodic market supply replenishment setting, SKU lifecycle status update, Planned Delivery Time (PDT) adjustment, and more.

When SOP is not digitally automated, the non value-added knowledge becomes a knowledge that has to be told from person-in-charge to another person and require training.