Depends on Customer

Today, I encounter another interesting requirements which state “depends on customer”. Being in project implementation for so long, I am still amused by this response. Why are there such requirements? Do not be surprised as such response is actually very common in Asian countries.

关系 as requirements

Asia cultures plays a big part in influencing the customer requirements. The “关系” aka as customer relationship is an unseen and very strong force. This practice is much prevalent in China, Japan and South Korea. It is no surprise that requirements can change upon customer requests. Naturally, it create challenges for the organisation as system is driven consumer customisation.

Customer is King

“Customer is King” is very common in Asia. With lower switching cost and labour cost, customers tend to be more fickle minded in Asia than American or EU countries. With the differences of leverages, organisations tends to accommodate customers for quick wins. Digital transformation also make it easier for customers to migrate their data across different platforms.

In Asia, requirements are driven largely by cultures. Power is a common play by customers to get what they wanted and as requested. You will usually need local help to elicit and mitigate such requirements. Only then, you can satisfy your customers and gain their trust.

IT Supply Chain Dilemma

Designing IT solution in Supply Chain is a constant dilemma. This is because we are trying to map the physical world into a digital plane. There will always be a constant timing and data gap in the system. So, how does we overcome this dilemma?

Managing Expectations

User expectations determines how you can tweak your supply chain system. The bullwhip effect actually applies for the information system as well. It is no uncommon for supply chain system to front facing to end users and vice versa. The dilemma happens when there is a mismatch of the system design with user expectations.

Real Time is Costly

Information flow is actually directly proportional to cost. The technology have provided cheaper real time information to users now. However, the change have not been effected to all existing systems built during the days of 2000s. It may take another five years or so before real time is the become a de facto standard. Meanwhile, it is a fact that all supply chain systems are only Near real time.

Many solutions that promised real time information update is nearly a hoax and dilemma in the year 2020s. This is because the physical world is not yet ready to provide such updates. By managing user expectations, you can deliver supply chain that achieve consumer satisfaction and not burden your IT team.

Handling Dead Codes and Processes

Ever encountered dead codes and processes? I have been cleaning many of such dead codes and processes. Usually, these happens to system that have been around for more than 5 years. Dead codes and process are usually system features that users no longer required or understand. These are some quick approach to handle them for removal.

Happy Path Approach

When you upgrade an old system to a new one, you should first plot the happy path. In daily operations, 80% of the system usage are on happy path, 10% on exceptions and the rest are manual handling. Using happy path approach, your system migrates all the key essential functionalities. This way, you can also clean up the dead processes and its corresponding codes.

I Don’t Know

Users compartmentalise system usage in their thought processes. As times goes by, fanciful nice to have features are forgotten and languish in neglect. Querying uses on these features will get a response of “I don’t know”. As a rule of thumb, these features are considered “dead” and can be removed with no impact to existing system.

These dead codes and processes often results in degrades of system performance and unnecessary costs in support tickets. Thus, it is a good exercise to clean up dead codes and processes when you are upgrading your legacy system.

Job Remodel

I had a meal at MacDonald today and observe that the role of cashier have been eliminated in this MacDonald branch. In place of it, self service kiosk are present. You can now even get your meal serve to you via table service. This gives a pleasant customer experience beside the quick and fast food meal we know in MacDonald.

Self Service

Self service gives customer control of their experience in the purchase of services and goods. This reminds me of scenarios where users claim that these tasks are too technical and refuse to self service. The model is nothing new and exist in early days like ATM and kiosks. Jobs will be remodel and those who refuse to change will be obsolete like the cashier role in MacDonald.

Experiential Investment

By participating in self service, consumers are invested in their own experience. This also creates loyalty and trust with the products. All these factors give rise to higher consumer satisfaction. This model can be applied for all systems. Digital transformation is the trigger to change and enhance customer experience instead of requirements fulfilment. Products and services are reaching a saturation point that customer experience is the differential factor.

Job remodelling will continue for next 5 years in tandem with digital transformation. It is either to embrace or be eliminated. There is nothing 麻烦 “troublesome” as these are the facts to be.

Language Localisation

Localisation is a key component of TMS (Transportation Management System). Legacy system suffers from language localisation partly due to database design which forces the implementation to be encode in certain locales. Globalisation of application creates new solution architecture which default localisation. One of such settings is the configuration of languages and display text.

Source: Telegram
Language Perspective

One may think languages in system is pretty straightforward. However, to a system, English does not literally mean English? Due to complexity of languages, we seek some sanity to classify languages in system. One of such classification is ISO 639. However, this is not the standard adopted by system due to different computer organisations. For instance, Windows language encoding will vary from that in Linux. The application SME (Subject Matter Expert) must be familiar with language localisation encoding across various platforms.

Future Language localisation

At present and in near future, we will see NLP (Natural Language Processing) gaining popularity like Chatbot. There will be focus for system to localise naturally from user behaviour and geolocation. Translation are real time and ML (machine learning) driven. Data locales are no longer required as data can be stored as what it is and translated as such.

Value Chain Redefined

The concept of value chain is not new. It is time to give a new meaning to value chain for the year 2019 and onwards. A pandemic like COVID-19 have redefined value chain to a new dimension.

Classic Value Chain

A value chain is a set of activities to create a product or services with the objective of maximising profit and create a competitive advantage. You will find standard raw materials or resources as inputs and finished products or services as end products. Supporting activities like HR, IT and logistics exists to smooth the operations of this process.

Value Chain Redefined

From COVID-19, value chain are tightly coupled with itself for end to end visibility. Social responsibility and sustainability triggers the evolution of value chain. Digital Transformation displaces old value chain and create new ones. New paradigm are formed where Agile invoke the innovation of customer experience.

In a nutshell, do be prepared for the new chain by acquiring new skillset and mindset. It is no longer viable to retain your old value chain. It’s now or never.

AMS vs DevOps – Month End Closing

It is month end closing! The first day of the month is usually the financial closing month as well. From a system view, there is always a heavy server load from last minute orders or batch job running monthly. This usually cause a whole lot of recurrent issues. I will do a quick comparison on how AMS (Application Managed Support) and DevOps view this standard issue.

AMS (Application Managed Support)
  • AMS will wait for issues to occur and await instructions to react and rectify the issue.
  • More support tickets will mean more job done.
  • The issue are addressed at face value. There will not be RCA (Root Cause Analysis) unless requested.
  • AMS resolve symptoms to ensure low severity and faster SLA
  • AMS are measured by SLA from support ticket. It is usually worthwhile to repeat same ticket type as response time will be fast due to known issues.
DevOps
  • Problems and risks are mitigated with business and system development knowledge.
  • Zero support tickets is the key objective to system stability.
  • DevOps conduct RCA for all issues and proposed enhancements or BPR (Business Process Re-engineering) resolve the root cause.
  • DevOps adopt short term and long term fix to prevent further recurring issues.
  • DevOps can be measured by low support tickets and positive Customer Experience (CX).

From the comparison, you can see the obvious benefits of transforming your AMS to DevOps. However, there is a reality that DevOps are much costly than AMS. So, which approach should you be going for?

Book Review: Competing in a Flat World: Building Enterprises for a Borderless World

The article on network orchestrators reminded me of my first book on this topic – Competing in a Flat World: Building Enterprises for a Borderless World. The networked economy and networked effect are research of topic then. This book focus heavily on a case study on the logistics company called Li & Fung. No spoilers below.

Source: Amazon
  • This book provides a case study approach to network orchestration.
  • You can have a look on the complexity world of logistics.
  • Logistics involves a complex network and mesh of tacit and explicit knowledge and relationships.
  • You can see how competitors are no longer a single entities but a network of alliances and coopetitors.
  • Organisation are leaning towards affective factors like brand loyalty, trust and relationships.

Overall, it is a smooth read and not so academic in nature. If you like case study, this is the book for you.

Measuring Satisfaction

The measurement of satisfaction have always been elusive. Many application system have not caught onto measuring satisfaction except for gaming. This is because gaming rely heavily on affective feeling. It is good to see your in-game character or account showing positive health or satisfaction. How should the mainstream adopt such format to measure satisfaction? These are some of ideas to get the product owner thinking.

  • Allow Satisfaction to be quantified and be calculated like Brand Value.
  • Make it simple to configure for satisfaction measurement.
  • Show clear display of satisfaction measures.
  • Consider satisfaction for cultural and localisation.
  • Let your CX (Customer Experience) team own the satisfaction index.
  • Benchmark against your country Satisfaction Index e.g. Customer Satisfaction Index of Singapore (CSISG).

CX Team

Customer Experience (CX) teams and careers are sprouting here and there. One wonder on what exactly does CX really do? How do you really embark on a career that is dependent on Experience? Although CX aims to bridge all touchpoints for customer, we are still lacking in knowledge of what CX really encompasses. This is a brief understanding of the key points on CX.

CX Lifecycle

CX Lifecycle is a simple method to model an end to end relationship with the organisation. It is widely studied in CRM (Customer Relationship Management). CX system are touted to be an upgrade of CRM. However, it suffers from similar issue for CRM because many backend and vendor system are not integrated or networked to form a complete lifecycle. Without networked information, the lifecycle cannot be view in completeness.

CX Indicators

Like my study on overall consumer satisfaction, the satisfaction indicators seek to measure the entire CX lifecycle. The creation of these indicators often involve many puzzles to be addressed. CX team must take ownership to plug the gaps or get these measurements. Often, CX team only support the engagement and monitoring process of these indicators. The ownership of the indicators still remains with individual application owners. This reduce the CX effectiveness when the driver and ownership is not from CX team.

It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you’ll do things differently.

Warren Buffett
Continue reading “CX Team”