System demo is getting easier now. However, a demo is not to be mistaken for POC (Proof of Concept). Non IT users often cannot differentiate between demo and POC. Here are some quick tips to know the differences.
Demo vs POC
The distinct differences between demo and POC are related to time, scope and cost. Demo are faster to show because you will be using existing test or demo data. Demo scope is limited to standard features that have already been implemented. Best of all, demo usually is free of charge. In contrast, POC may not be free because you would be setting up customer data for POC. In some cases, you may configure specific features pertaining for customer requests. Thus, POC will take a longer duration to be planned and setup like a project.
Set Your Expectations
When you are going to showcase your system, it is important to set the customer expectations. Non IT users also have the misconception of using excel for simulation and anticipate the system to behave in similar manner. The expectations will determine if your customers are looking for a demo or POC. You will need to plan your schedule carefully based on these expectations.
It is not surprising to see sales or non IT users mixing up the customer expectations for demo or POC. You may find yourself in a crunch to provide freebies POC as a disguised demo. Therefore, it is timely to educate your users on the key points for demo and POC
Many users or sales have the misconception of pleasing customer with promise of customisation to your system. However, this is not true as some services are better to be standardised and cost efficient. There is also a limit to please your customer without hurting your bottomline. What are the guidelines to avoid customising your system?
A Product View
Moving your business towards a product view is the first step to understand your customer base. A key reason of customisation is the fit of your product to customer needs. A poorly fit product will result up in a lot of customisation. You must adapt your product to fit the your targetted customer base. A well designed product should have a deviation of 10% customisation and 10% localisation.
Know your Customers
When you have decide to establish your application as a product, it it time to categorise your customer base. Your understanding of customers are important to refine your product into various types. High-end and well-paying customers can be provided with all the bells and whistles in applications. In contrast, you may not want an economic customers to be using your full featured product.
The basic guideline to stop the customisation trend for your application is to start thinking like a product. With a product view, you can position your application to each customer base. This will reduce your cost and increase your customer satisfaction with a better fit of product at valued pricing.
Should we have reopen as our status value? If you are familiar of status lifecycle values, you will realise that this is a very ambiguous status value. If you have the option to reopen, there will be no end to status. This is because your statistics will mess up due to this reopen.
If you are in engineering, you will learn about state diagram. It is a very good concept to manage your status value and its logical flow. Users love to provide various value for your status. Very soon, you may find overlapping status or conflicting status for your application. Give this method a try if you are facing a status meltdown.
Setting good status value is key to analysing your transactions. These are some good tips to setting good status and its values.
Keep your status type to less than 3 if you want to remember the status dependency.
Set your status value in a forward logical flow.
Avoid ambiguous status like reopen that will mess up your statistics.
Do not create conflicted status value for status type like Done for a status and “Pending” for the other.
Always have a start and end state to your status.
Status are key method in all data gathering and analysis. Users may not be the best person to determine the status. You may want to review and use state diagram to illustrate your status flow. Keep in mind the status tips to extract the best results in your data.
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.
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?
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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?