As companies grow, asset management becomes crucial for smooth operations. Smaller firms manage with MS Excel or plug and play solutions, but multinational companies need dedicated systems due to their complexity. Large companies often build custom systems as off-the-shelf solutions fall short. This case study outlines how Infosys' asset management team revamped their legacy system to boost efficiency, cut costs, and enhance control and accountability.
Infosys, a multinational based in Bangalore, India, employs around 250,000 people across 46 countries. With over eight development centers in India and smaller offices globally, Infosys manages a diverse range of assets, including software, hardware, land, buildings, intellectual property, and facilities like vehicles and furniture.
Each type of asset at Infosys presents unique complexities and requires distinct accounting and management approaches. Some of these complexities include:
Adding to the mix, assets are owned by different departments within Infosys, each with its own hierarchy and approval mechanisms:
In addition, several other departments at Infosys play crucial roles in asset management:
The complexities and departments mentioned above evolved over time. Whenever a new requirement emerged, it was either added to the existing system or a new system was created. This resulted in three different systems to manage assets:
Over time, as new features and processes were added, the systems began to show breakages, slowdowns, and other critical performance issues. It reached a point where further development of the existing systems could no longer resolve these issues.
Additionally, an external compliance team identified major problems and recommended that Infosys's top management rethink their asset management process. Consequently, the management directed the asset team to identify all underlying issues and propose a comprehensive solution.
The Asset team identified all known internal issues and conducted one-on-one meetings and group discussions with various departments and hierarchies to uncover additional underlying issues. The major pain points were:
The Asset team shared their findings with top management and all relevant stakeholders. They highlighted the major pain points, emphasizing the integration issues, outdated workflows, lack of feedback mechanisms, data duplication, and system architecture problems.
To address these issues and accommodate future requirements, the team recommended developing a new system with a modular architecture - the Asset Management System (AMS). This new system would be designed to seamlessly integrate with existing systems, support updated workflows, provide real-time notifications, ensure robust data management, and enhance security and access control.
After numerous meetings and detailed discussions, management and stakeholders reviewed the proposal thoroughly. They considered the long-term benefits of implementing a scalable and efficient AMS, which would streamline asset management processes, reduce operational costs, and improve overall accountability.
With a clear understanding of the necessity and potential impact of the new system, the management and stakeholders gave their approval, signing off on the proposal to develop the new Asset Management System.
A step-by-step plan was created to achieve the proposal:
The existing three systems lacked proper documentation, so the first step was to thoroughly understand and document the current system. Once the documentation was complete, it was shared with different stakeholder groups to educate them on the existing features and processes.
The stakeholders reviewed the documentation and provided feedback, suggesting changes and new additions. These suggestions were then refined into workflows and processes. Detailed discussions with the stakeholders helped prioritize the importance of each step, leading to the consolidation of steps and the elimination of redundant processes.
Additionally, the team conducted sessions with employees at different levels within each stakeholder group to understand their usage of the system and the real-time problems they faced. This approach helped uncover ground realities and assess the employees' technical literacy, providing new insights that contributed to improving the Information Architecture.
The new system will adopt a modular structure, with Asset IDs serving as the base data and integration with the SAP system being pivotal. Master databases will be established for Hardware, Software, and Facility asset IDs, along with an employee details database updated from the HR system. Each module will have its own database, governed by specific rules and restrictions.
Infosys employs an internal design system for its applications, which will serve as the foundation for the AMS (Asset Management System) UI and interactions, albeit with some customizations.
Streamlining roles is crucial; currently, there are over 25 roles across the three systems, with redundancies and duplications. By consolidating roles, we've reduced the count to 15.
AMS roles will be overseen by a centralized system managing roles for all internal applications, ensuring proper configuration and access. Access permissions will be granted exclusively by top officials within each stakeholder group.
We first broke down the requirements into separate features. Then, we created wireframes for each feature and page. Once these wireframes were approved, we began the development phase. The application development follows the agile methodology.
Once a module is developed and tested, it's released to stakeholders. Before the release, users are trained on the application's features. Detailed help documents are provided for reference.
Module releases are phased, starting with 1-2 campuses and selected stakeholder groups. Feedback is gathered and issues addressed before wider release.
AMS faced several challenges typical of product development. Conflict arose among stakeholders despite initial agreement on requirements and architecture, causing delays. Changes to processes or requirements after module releases added extra work for the development team. Additionally, some users were reluctant to adopt the new system, necessitating further training.
As of the end of 2019, the team had successfully completed 75% of the modules. A significant lesson learned from this project was navigating the complexities of revamping a product within a traditional organization with multiple layers of hierarchy and stakeholders.