So you probably had the initiative of suggesting K2 to form part of your master plan and the K2 sales team did a great job in selling the product by building workflows and solutions on the fly to demonstrate the possibilities.
By now every department has heard of this initiative and the pressure is on for the IT crowd to deliver. This is where you have to calm down, take a deep breath and find the best way to implement K2 in the context of your situation. For a growing number of organisations, the optimal way is to deploy small manageable projects, one at a time that forms part of the bigger rollout strategy. Naturally in many cases Agile project management is a great way to approach shorter development life cycles to maximise outcomes.
At this stage, you already have the ideas and suggestions from your management team on what areas need attention, but let’s pause and go back a few steps. Hereby a couple of tips and tricks based on my experience to date:
- Firstly plan the IT strategy flow diagram to see the high-level data flow and colour code the processes, communicate with all levels of business, from the stakeholder to the end user and make sure the flow diagram is reasonably mature.
- Make sure to spend enough time with the end users to fully understand their needs and get close enough on what they do on a day to day basis. While management team members might be good at setting direction, the users capturing the data is ultimately responsible for maintaining the data. Remember GIGO (Garbage in Garbage out). Keep in mind the main objective is to make the work easier for the end users.
- Identify the key problem areas and prioritise your findings. Create a proper scope for every problem area and make sure the developer understands the process better than the end user. Don’t be afraid to challenge the user, you might discover the user wants some functionality that is already part of the master design, it might just need minor adjustments to implement.
- Reporting and dashboards are key elements to success, so keep that in mind when designing your solution and when identifying your target.
- Use K2’s recommended Development, UAT and Production typology wisely in support of a healthy SDLC (Software Development Life Cycle). No development should be done on UAT or Production environments. It is a good practice for the UAT environment to mimic the Production environment. It is always a good idea to avoid sharing solution assets between development UAT, and Production environments. A proper segregation of these assets will ensure that the package and SQL scripts are already tested during deployment from Development to UAT environment, by the time of deploying from UAT to Production environment.
- In the event that you have limited SQL skills on your team or working with a small amount of data, K2 SmartBox may be a good way to go, especially given the implementation speed and simplicity benefits offered by the K2 SmartBox. If you have excessive amounts of data, consider creating and managing your own database, for flexibility and performance. From a K2 upgrade and support perspective, it is a good idea to implement any custom SQL assets on a separate SQL Database.
- Lastly, it’s always a good idea to learn from the experience of others. The K2 Solution Accelerator initiative is a valuable source of information on how common scenarios can be implemented. These Solution Accelerators are predefined solution examples that include Leave Request, New Idea Submission, Expense Claim, Ad hoc Task Management, Travel Request, Incident Management and others. While K2 Solution Accelerators are great to get you up and running, do not forget about your master design, and how these Solution Accelerators will interact with your current and future planned systems (the last thing you need is master data everywhere, so use with consideration).
I hope and trust the points discussed above will be of good value in helping you to get a successful start when implementing K2 in your business and get you going in the right direction.