Having completed two end-to-end implementation projects for Customer Master and Vendor Master Data governance solutions using Netweaver BPM and Netweaver MDM in the last one year we were consistently getting different requiremnts for the Workflow solution. Different type of users laid emphasis on different things and it was a herculean task to satisfy all the requirements, so we made some tradeoffs and arrived at the final solution which more or less satisfied the ‘critical' needs for all the users. Below are some of the requireents that came up from different type of users:
End Users: These were the users from the field force of the customer organization and had very little to nil technical knowledge. Their main concern was the availability of the solution over the PDA/Smartphone/Blackberry, reason given was that they are always carrying mobiles and it will be very user friendly and they do not necessarily have their notebooks connected to internet every time or while travelling. We had to turn down the request citing the technical feasibility as BPM is currently not supported on mobile devices.
Master Data Stewards: Master Data Steward team that owned this solution wanted that all the requests should be archived and the data processed in a particular request should be permanently stored somewhere physically or in electronic document format. Initially we did not plan anything in this regard but later we proposed a solution for generating PDFs for each request and storing it.
SOX Compliance Team: SOX Team came up with several requirements for additional controls to restrict the access and track the changes done to that data. On of the major thing that they wanted to get implemented was to maintain a log of changes at all levels in a process (If we have four approval steps along with one request step, then they wanted that one PDF is generated and stored at each step). Maintaining such a huge volume of data for requests would have been a nightmare and so we agreed for a more logical solution by mutual agreement.
Business Users: Business wanted the master data to be created as early as possible and if they were given a choice, they would have removed all the approval steps from the workflow and would have loved to create the data directly without any approvals.
Management: For management, the most important information coming out from this implementation was a way to measure the Key Performance Indicators. Management wanted to measure the KPIs against agreed SLAs to identify and remove bottlenecks, run improvement programs and make proper decisions. We proposed a customised KPI reporting solution to the client which had request tracking, comprehensive search capabilities and reporting features.
We arrived at a consensus by clearly showing the tradeoffs in cost vs benefit and we simply left requirements that were 'Nice to have' and not critical to the business.
End Users: These were the users from the field force of the customer organization and had very little to nil technical knowledge. Their main concern was the availability of the solution over the PDA/Smartphone/Blackberry, reason given was that they are always carrying mobiles and it will be very user friendly and they do not necessarily have their notebooks connected to internet every time or while travelling. We had to turn down the request citing the technical feasibility as BPM is currently not supported on mobile devices.
Master Data Stewards: Master Data Steward team that owned this solution wanted that all the requests should be archived and the data processed in a particular request should be permanently stored somewhere physically or in electronic document format. Initially we did not plan anything in this regard but later we proposed a solution for generating PDFs for each request and storing it.
SOX Compliance Team: SOX Team came up with several requirements for additional controls to restrict the access and track the changes done to that data. On of the major thing that they wanted to get implemented was to maintain a log of changes at all levels in a process (If we have four approval steps along with one request step, then they wanted that one PDF is generated and stored at each step). Maintaining such a huge volume of data for requests would have been a nightmare and so we agreed for a more logical solution by mutual agreement.
Business Users: Business wanted the master data to be created as early as possible and if they were given a choice, they would have removed all the approval steps from the workflow and would have loved to create the data directly without any approvals.
Management: For management, the most important information coming out from this implementation was a way to measure the Key Performance Indicators. Management wanted to measure the KPIs against agreed SLAs to identify and remove bottlenecks, run improvement programs and make proper decisions. We proposed a customised KPI reporting solution to the client which had request tracking, comprehensive search capabilities and reporting features.
We arrived at a consensus by clearly showing the tradeoffs in cost vs benefit and we simply left requirements that were 'Nice to have' and not critical to the business.
