WORKFLOW MANAGEMENT. Varun Goel. MBA Final Year DoMS, IIT Roorkee Project Guide. Dr. N.P. Dhavale

Transcription

1 WORKFLOW MANAGEMENT Varun Goel MBA Final Year DoMS, IIT Roorkee Project Guide Dr. N.P. Dhavale Deputy General Manager IDRBT, Hyderabad

2 INSTITUTE FOR DEVELOPMENT AND RESEARCH IN BANKING TECHNOLOGY (IDRBT) Road No. 1, Castle Hills, Masab Tank, Hyderabad CERTIFICATE Mr. Varun Goel, doing MBA course at IIT, Roorkee in the Department of Management Studies (DoMS) was assigned the project Workflow Management as an intern at IDRBT, Hyderabad from May 14,2013 to July 12, This is to certify that he has successfully completed the project Workflow Management under my guidance. During the course of the project he has undertaken a study of documenting business processes and identifying KPIs. He was involved in fine tuning the process, suggesting enhancements and identifying business process management (BPM) tool. Dr. N.P. Dhavale (Project Guide) Deputy General Manager IDRBT, Hyderabad 2 P a g e

3 ACKNOWLEDGEMENT I would like to express my sincere gratitude to the Institute for Development and Research in Banking Technology (IDRBT) and particularly Dr. N.P. Dhavale, Deputy General Manager, IDRBT who was my guide in this project. I would not hesitate to add that this short stint in IDRBT has added a different facet to my life as this is a unique organization being a combination of academics, research, technology, communication services, crucial applications etc. and at the same time performing roles as an arm of regulation, spread of technology, facilitator for implementing technology in banking and non-banking system. I am extremely grateful to Dr. N.P. Dhavale for his advice, innovative suggestions and supervision. I would also like to thank Shri V.S. Mahesh, Shri E. Srihari and all other employees of INFINET department for their constant support and help in completion of my project. I would also like to thank my family and friends for the moral and emotional support. I am thankful to DoMS, IIT Roorkee for giving me this golden opportunity to work in a highend research institute like IDRBT. Finally, I thank one and all who made this project successful either directly or indirectly. Varun Goel MBA, Final Year DoMS, IIT Roorkee 3 P a g e

4 TABLE OF CONTENTS 1. Introduction About INFINET About Workflow Benefits of Workflow Objectives Document the business processes of INFINET Identifying KPIs and Enhancement of Processes Identifying Business Process Management Tool Methodology Flowcharts Identifying KPIs & Enhancements Identifying BPM tool Business Processes of INFINET Monitoring Process MPLS Helpdesk Process SLA Process SLA Payment Process Invoice Generation Process Security Helpdesk Process BPM tools Analysis of various BPM Tools About Working of Bonita BPM Conclusion Future Prospects References Annexure P a g e

5 LIST OF ABBREVIATION BPM CRF EFT ETR ICMS IDRBT INFINET KPI MPLS NAT NNM NOC PAT PRTG RBI RFO SBU SLA : Business Process Management : Change Request Form : Electronic Funds Transfer : Expected Time to Recovery : Incident cum Change Management System : Institute for Development and Research in Banking Technology : INdian FInancial NETwork : Key Performance Indicator : Multi- Protocol Label Switching :Network Address Translation : Network Node Manager : Network Operation Centre :Port Address Translation : Paessler Router Traffic Grapher : Reserve Bank of India : Reason for Outage :Change Request Form : Service Level Agreement 5 P a g e

6 ABSTRACT Workflow is defined as depiction of sequence of steps, tasks or operations involving work of a person or organization, required input and output information, tools used for each step in a business process. Indian Financial NETwork (INFINET) is one of the SBUs of IDRBT. It is the communication backbone for the Indian Banking and Financial Sector. It caters various inter-bank and intra-bank applications like SFMS, MIS, EFT, ECS, etc. The aim of this project is to incorporate workflow management into the business processes of INFINET. The various processes involved are MPLS helpdesk process, SLA process, SLA payment process, Invoice generation process, Monitoring process and Security Helpdesk process. The technique used to depict these processes is through flowcharts. The information about the processes is gathered from people working on it and the higher authorities of INFINET. The key performance indicators (KPI) are identified for each process. These KPIs are identified by understanding the similar processes and KPIs used in other organizations. Then, suggestions are given to enhance/improve the overall process. Further, workflow management tools/business process tools are identified in which these processes could be incorporated. 6 P a g e

7 1. INTRODUCTION 1.1 About INFINET The INdian FInancial NETwork [INFINET] is one of the SBUs of the IDRBT. It is the communication backbone for the Indian Banking and Financial Sector. All banks in the public sector, private sector, cooperative, etc., and the premier financial institutions in the country are eligible to become members of the INFINET. The INFINET is a Closed User Group Network for the exclusive use of member banks and financial institutions and is the communication backbone for the National Payments System, which caters mainly to inter-bank applications like RTGS, Delivery Vs Payment, Government Transactions, Automatic Clearing House, etc. 1.2 About Workflow Workflow is defined as depiction of sequence of steps, tasks or operations involving work of a person or organization, required input and output information, tools used for each step in a business process. In simple language, workflow is the pictorial representation of each step of a business process. It involves right from the task performed by a person, the information required to initiate and complete the process to tools required in completion of process. Workflow may either be sequential, with each step contingent upon completion of the previous one, or parallel, with multiple steps occurring simultaneously. 1.3 Benefits of Workflow Workflow management improves efficiency as automation of business processes could be done. Automation will provide the organization more benefits. It will reduce the number of tasks to be done by an employee manually, thus freeing them to work on the other important tasks. This will allow more number of things to be done in same amount of time. It will also reduce the repetitive tasks thus increasing productivity. Reduction of repetitious work might also increase employee motivation as their job would be more interesting and they can spread out into other areas of work as well. Process control management and quality of outcomes could be improved by workflow management. Better business control could be achieved by standardizing work methods. There will be fewer chances of mistakes occurring, so organization can generate higher quality outcomes. Customer service and satisfaction could also be improved by using workflows. Process consistency could be achieved by workflows thus improving customer service from predicted processes, responses and high quality service. Overall, business process improvement is achieved as the main focus is on the business processes. 7 P a g e

8 There are three main objectives of the project: 2. OBJECTIVES Document the business processes of INFINET. Identifying KPIs and enhancement of process. Identifying business process management tool. 2.1 Document the business processes of INFINET The first objective is to document the business processes of INFINET. For improving any business process, it is essential that documentation of process should be done. Documentation reduces operational ambiguity, can act as training material for new recruits and can be used to project the clear picture of any organization in the market. There are six business processes of INFINET which are documented. These are as under: A. Monitoring process B. MPLS Helpdesk process C. SLA process D. SLA payment process E. Invoice Generation process F. Security Helpdesk process All these processes will be discussed in detail further in this report. 2.2 Identifying KPIs and Enhancement of process The next objective is to identify the KPIs for each process and suggesting enhancements to improve the quality of the process. KPI is Key Performance Indicator. KPI is a set of measures that an organization uses to evaluate the performance of the organization. An organization may use KPIs to evaluate its success, or to evaluate the success of a particular activity in which it is engaged. Success here is defined as simply the repeated, periodic achievement of some level of operational goal. In simple terms, KPIs tells what is important in the process. This leads to the identification of potential improvements. By focussing on the important part in the process, the enhancements could be suggested to improve that particular part thus improving the overall quality of the process. 2.3 Identifying business process management tool The final objective of the project is to identify the business process management (BPM) tool so that all the business processes could be incorporated into the tool. BPM tools could be helpful in designing business process models, process flow models and also helpful in simulating, optimizing, monitoring and maintaining various processes within the organization. The use of BPM will provide organization the strategic values like quality of service & customer satisfaction, operational excellence & productivity, business agility, employee motivation & collaboration and risk management. 8 P a g e

9 3. METHODOLOGY 3.1 Flowcharts To achieve the first objective of the project, depiction of business processes needs to be done. The technique used to depict the business processes is flowcharts. A flowchart is a type of diagram that represents a process, showing the steps as boxes of various kinds, and their order by connecting them with arrows. Process operations are represented in these boxes, and arrows; rather, they are implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process in various fields. Flowcharts are chosen as a technique to depict the processes as it is a better way of communicating the logic of a process. With the help of the flowcharts, problems can be analysed in a more effective way. It serves as good program documentation. Often, flowcharts are the guide or initial input to an automation process. 3.2 Identifying KPIs & Enhancements After each of the business processes of INFINET is documented, KPIs are identified for each process. This is done using internet. Processes in other organizations similar to the business processes of INFINET are identified. Then, key performance indicators used by these processes are analysed and applied to the business processes of INFINET. After identifying KPIs, the enhancements are suggested by keeping the main focus on these performance indicators only so as to save the time involved in the process and improve the quality of the process. 3.3 Identifying BPM tool Major BPM tools widely used in the organizations are identified. For each tool, the key features, open source availability, ease of use and application feasibility to business processes of INFINET are analysed and best tool is identified which could be used to incorporate the business processes of INFINET. The different open source BPM tools analysed are as follows: Bonita BPM jbm Camunda BPM Activiti BPM Process Maker Intalio 9 P a g e

10 10 P a g e 4. BUSINESS PROCESSES OF INFINET There are six business processes of INFINET which is covered in the project. For each business process, a flowchart has been prepared which is present as the Annexure. For each process, KPIs & Enhancements are provided at the end of each process. Each business process will now be discussed in detail in this section. 4.1 Monitoring Process Monitoring process involves the monitoring of links at RBI locations and other member bank locations. There are around 44 RBI locations and 650 member banks links all over the India. All these locations have one/two routers through which it uses various banking applications catered by INFINET. These routers links are provided by two service providers Reliance & Sify. The monitoring process involves monitoring of working of these links. There are two tools which are used for monitoring in the IDRBT PRTG (Paessler Router Traffic Grapher) & SolarWinds. The monitoring desk also acts as intimation to MPLS Helpdesk team. The monitoring process is depicted in the flowchart A. The process involves these steps: A1: In case of any issue, the monitoring tool will detect the issue and send the alert mail to the concerned person. A2: As alert is received, the router status is checked through logs. These logs are of a particular device or link which has been broken down. The logs are checked to confirm the status of router. A3: MPLS team raises the ticket for each issue with the service provider for its resolution. In this step, it is checked if the ticket has been raised by MPLS team for an issue. The raised ticket is seen in ICMS (Incident cum Change Management System). A4: If the ticket has not been raised by the MPLS team, then the MPLS helpdesk team is intimated about the issue and asked to raise the ticket immediately. A5: If the ticket has been raised by MPLS Helpdesk team, then the status of the ticket is seen & monitored in ICMS. A6: At the end of each month, report for all the routers is generated separately through each tool. This report includes graphs showing downtime, total traffic, traffic in & out, packet loss etc. A7: These reports are then sent to the SLA team which uses it in SLA calculation process. KPIs for Monitoring Process Time required for intimation to MPLS helpdesk team This is the time required to intimate the MPLS helpdesk team about the issue, if they have not raised the ticket. This time should be as low as possible. Efficient Monitoring of routers This is how well the monitoring of routers/links is done. It involves how quickly alert mail is coming in case of any issue. This should be as efficient as possible.

11 Enhancements for Monitoring Process Documentation about resolution time A proper documentation could be prepared for each issue and its resolution time. That is, after how much time for a particular issue, MPLS team should be informed. This should be documented as this would increase the consistency in the process, thus improving it. Adding more routers to monitoring tool Only important routers are being monitored right now by the monitoring tools. Among the tools used now, the best tool could be selected by doing comparative analysis and more routers could be added to that tool for monitoring. This would increase the efficiency of monitoring as more routers could be covered. 4.2 MPLS Helpdesk Process MPLS Helpdesk team is the helpdesk centre for all the RBI locations & for member banks. In case of any issue with the MPLS Connectivity router or link, MPLS helpdesk is contacted by them. MPLS team works in three shift timings 7:00 AM to 2:00 PM 2:00 PM to 9:00 PM 9:00 PM to 7:00 AM The helpdesk will receive issues or incidents through Phone Calls, , Letters and through proactive monitoring analysis. At any point of time, at least one technical engineer is present for attending and addressing the issues. In general, 2 technical engineers are there at a time. MPLS helpdesk is supported by another team, Remote NOC (Network Operation Centre) team. The NOC team is currently in Noida. The scope of work of NOC s team is to proactively monitor the links and report the issue. The main objective of MPLS team is to attend issues or incident and should not be missed, should be reported to IDRBT and resolved at the earliest. Apart from this, MPLS team also has a kiwi backup tool. With the help of this tool, the backup of the router configuration of all RBI and other member bank locations has been stored. This backup is generally taken in a week. The MPLS Helpdesk process is depicted in the flowchart B. The process involves these steps: B1: NOC team proactively monitors the entire network. All these links are monitored by using a tool NNM 9i. It is a network node manager tool by HP. Under this tool, monitoring the links, downtime of links, performance of the service could be monitored. There is another tool used by IDRBT Solar Winds. This tool monitors the links of RBI locations only. B2: In case of any link breakdown or issue, it is detected by the NOC team. Only logical issues are not detected by NOC team. Logical issues are those issues where link is up & working fine but 11 P a g e

12 still some applications are not working for the banks. These issues cannot be tracked by NOC team. These kinds of issues are critical one and are reported directly to MPLS team. B3: As the issue is being detected, it is reported to the service provider by NOC team. NOC team raises a ticket with the service provider in which the details of the issue are being raised. As the ticket is raised, an alert mail is sent to the MPLS service desk about the issue & ticket. B4: After raising the ticket, NOC team records the issue by updating BMC Remedy tool. This tool enables to monitor the status of the ticket. Under this tool, down time, reason of downtime, expected time to be taken to rectify it, up time and other details are recorded by NOC team. B5: As the bank detects the issue, it reports it to MPLS helpdesk centre through telephone or E- mail or post. B6: MPLS service desk is also monitoring the links on its own using tools like NNM 9i & SolarWinds. B7: As the issue is being reported by bank to service desk, it is checked if the ticket has been already raised by NOC team. If it has been already raised by the NOC team, then the bank is informed about the ticket. B8: If the ticket is not been already raised, then the ticket is raised with the service provider after understanding the issue. B9: At the service provider end, the issue is seen and on the basis of known error & understanding of issue, ETR (Expected Time to Recovery) is calculated. B10: The ETR from the service provider is provided to the MPLS helpdesk team. B11: The business impact of the issue is analysed and understand by the MPLS helpdesk team. If the business impact is not that high, the ETR & status is being informed to the bank. B12: If the business impact is high, then the working of alternate connection is checked. In case of any issue or problem in the alternate connection also, the higher authorities of IDRBT are informed. B13: On the service provider side, the issue is being understood, analysed & resolved by the engineers of service provider. B14: The status of the issue is being updated by the service provider to NOC/MPLS service desk. MPLS service desk/noc team also follow up continuously with the service provider on the issue. B15: The bank is kept informed about the status of the issue or resolution of the issue by the MPLS helpdesk team on each follow up with service provider. B16: As NOC team records all the issues in BMC Remedy tool, MPLS team records/updates all the issues in ICMS (Incident cum Change Management System). The issues which are raised by RBI locations are being downloaded from ICMS for SLA calculation. B17: MPLS helpdesk team prepare a closure report which is being sent to the banks. This report includes the reason of issue, resolution of issue and other details relating to the issue. 12 P a g e

13 KPIs for MPLS Helpdesk Process Time taken to answer call or responding to mail This is a time taken to answer the incoming call on the telephone, that is, after how many rings or seconds the phone has been lifted. Also, the time is taken to reply to the if the issue has been communicated through the mail. This should be as minimal as possible. Time taken to raise the ticket This is the time taken to raise the ticket with the service provider. It includes the time in which the issue is being understood and ticket has been raised with the service provider. This should be as minimal as possible. Efficient follow-up This is how well the follow up is being done by the team with the service provider on the status of the issue and how well it is being communicated back to the banks. This should be as efficient as possible. Sending closure reports to banks This is the time taken by the MPLS team to prepare the closure report and send it to the respective banks. This time should be as low as possible. Enhancements for MPLS Helpdesk Process IVR for critical issues IVR (Interactive Voice Response) system could be implemented in case of any critical issues. Critical issue may be like an issue with the data centre which affects large number of banks. In such cases, as the number of phone calls to the MPLS helpdesk team is a very large number and all calls could not be attended by the team, IVR system may be helpful as the banks would automatically comes to know about the issue being critical and issue is being worked upon, thus increasing the satisfaction of bank representatives. Ideal Call flow questionnaire An ideal call flow questionnaire could be prepared for some common type of issues. This would help the MPLS team members as there will be a particular set of questions which needs to be asked to the bank representative about the issue through which the issue would be more clearly understood and more quickly the ticket would be raised with the service provider, thus saving time. Common platform for MPLS team, service providers and banks A common platform could be made where status of the issue could be shared. This platform would help the service providers, banks & MPLS helpdesk team as follow up would become more efficient and less cumbersome. This would also save the time which is being spent during the follow up activities. 13 P a g e

14 Sound Effects in outlook For , sound effects could be made on which would notify the arrival of a new e- mail with a sound. Also, the reminder sound may also be made on so as to notify and remind the MPLS team members in case of an unread mail. This would make sure that any mail is not missed and time to respond to the will also reduce. 4.3 SLA Process There are two service providers Reliance & Sify, which are providing the network services to RBI locations and other member banks. SLA is service level agreement. Under SLA, the service provider is required to provide a particular network uptime during a month failing which they will be given the less payment. The network downtime is decided on the basis of how much interruption/downtime/incidents has been reported and the service provider s responsibility in it. The SLA process is carried out for RBI locations only. The SLA process is depicted in the flowchart C. The process involves these steps: C1: From the ICMS (Incident cum change management system) application, an excel file is downloaded for each day/month. This excel file contains all the issues reported by MPLS team. The excel file contains many fields providing the information about issue in detailed manner. These includes Bank ID, Bank Name, location, logging and closing date & time, downtime, problem reported, cause of problem, service provider ID (SIFYTAC ID for Sify & RELIANCETAC ID for Reliance), resolution as reported by vendor, any attachments, etc. C2: Another excel file Reason for outage (RFO) is provided by service providers each day/month. Sify provides SIFY RFO and Reliance provides RCOM RFO. These files contain the issue details as provided by the service providers. SIFY RFO contains fields like Link ID, Case, link description, incident summary, opened & closed date, reason/resolution, etc. RCOM RFO have fields like Site name, ticket reference, problem type, create & resolved date and time, total hours, reason for closure, etc. C3: For Sify, Case field in SIFY RFO is matched with SIFYTAC ID field in ICMS sheet. For Reliance, Ticket Reference field in RCM RFO is matched with RELIANCETAC ID field in ICMS file. C4: A separate excel sheet is prepared contains some fields from both ICMS and RFO files on the basis of IDs matched. This sheet contains Link ID, TAC ID, Link description, Service provider location, ICMS location, RBI ID, Incident summary, TAC open and close date & time from both ICMS & RFO files, problem reported, cause of problem and resolution from both ICMS & RFO, HCL SLA, etc. In case of Reliance, Link IDs are different in RCOM RFO and ICMS, In RCOM RF, link ID is given in alphanumeric. C5: The above mentioned excel sheet is the final SLA sheet. The final SLA sheet for the day/month is prepared for both Sify and Reliance. Sometimes, there is also a duplicate data recorded by ICMS for the same issue. This data is also marked in the final SLA sheet so as to avoid the redundancy. 14 P a g e

15 C6: The final SLA sheet is sent back to the MPLS team so as to check the correct entry of all issues. This is done to verify whether all issues have been reported in the final SLA sheet or not. C7: After MPLS team reviews the sheet, it returns back to IDRBT. Again the final sheet is reviewed and if any discrepancy/modification is found earlier, it is again sent back to MPLS team after correction for another review. C8: This final SLA sheet is then sent to the service provider so that further discussion with the service provider could happen over this final SLA sheet. C9: Each issue in the SLA sheet is analysed and understood at this stage. It is seen whether the issue is due to the service provider s fault or it is due to the fault at bank location or from IDRBT side C10: Is the issue being analyzed is eligible for SLA or not is decided at this stage. It is generally eligible for SLA if the mistake is from the service provider s side. Only those issues which are eligible for SLA are taken up further. C11: The reason for the issue is analysed at this step. The resolution provided by the service provider is analysed. On the basis of understanding & analysis of issue, final downtime is decided for each issue. C12: Discussion between IDRBT & service provider happens over the issue & downtime is discussed for each issue. The final consensus is made on downtime to be frozen. C13: After getting consensus from service provider, final downtime is frozen for each issue in the final SLA sheet and the sheet is sent to the SLA payment process for further process. KPIs for SLA Process Efficient matching of TAC Ids This is how well the matching of Ids between RFO sheet provided by service provider & ICMS is being done. This should be as efficient as possible because any issue might get missed if matching is not done properly. Time taken to make final SLA sheet This is the time taken to prepare the final SLA sheet after matching the Ids and combining all the fields. This should be kept low as the others processes are dependent on it. Time taken to agree upon downtime This is the time taken to complete the discussion and resolve the issue on downtime within acceptable period of time. This should be kept minimal. 15 P a g e

16 Enhancements for SLA Process Using technology to match the TAC Ids Matching the technology manually could result into low efficiency and higher chance of error is there. To counter that, technology like SQL could be used to match the Ids. A small application could also be made to do this task so as to increase the efficiency. Developing application for creating SLA sheet Process like making final SLA sheet when done manually could take a lot of time. Apart from that, it is a repetitive process where many fields from two files need to be combined in one. If any application could be developed which could create the final SLA sheet, this would save a lot of time thus increasing productivity of a process. Documentation about common reasons A proper documentation could be prepared for the common reasons of downtime. As there will be a lot of repetitive issues having common reason, a proper documentation will make the analysis much faster, thus providing consistency to the process. 4.4 SLA Payment Process Under this process, the payment is being made to the service provider on the basis of the uptime provided by them during the month as per the already decided SLA agreement. The SLA agreement for purchase order for the Sify & Reliance is as follows for Category I: Level of network uptime for a given location per month Amount payable for supply of IP VPN Bandwidth, network management/maintenance >99.99% to 100% 100% of Purchase order value >99.94% to <=99.99% 90% of Purchase order value >99% to <=99.94% 80% of Purchase order value <=99% No payment The SLA payment process is depicted in the flowchart D. The process involves these steps: D1: Invoice for the particular time period (generally a month) is prepared by the service provider and is sent to the IDRBT. D2: The final frozen downtime is provided by the final SLA sheet. This downtime & the invoice details sent by service provider are matched to be correct. D3: The payment is done for each of the RBI locations. The Network uptime is calculated on the basis of final confirmed downtime at the given location as per the final SLA sheet and the total time provided by the service provider at that location. D4: As the network uptime is calculated, the payment to be done to service provide is calculated & finalised as per the SLA agreement. 16 P a g e

17 D5: Internal note, final SLA amount along with the monthly reports of SLA is send to the accounts department for payment to the service providers. D6: Auditors at accounts department verify & cross-check the correctness of SLA amount before sending it for final payment. D7: Accounts department releases the SLA payment through EFT to the service provider. Service provider receives the payment from IDRBT and confirms it back. KPIs for SLA payment process Time taken to calculate network uptime This is the time taken to calculate the network uptime for each service provider. Though it is not huge calculations, but calculating it for so many issues could become cumbersome thus increasing time. This should be kept as minimal as possible. Time taken to send the reports to accounts department This is the time taken to send the internal notes and final reports to the accounts department for further payment to service provider. This should be as low as possible. Enhancements for SLA payment process Developing application for calculation A small application could be developed which would automatically calculate the uptime for all the issues of each service provider. This would save a lot of time thus increasing overall productivity. Developing common portal A common portal for the accounts section and SLA team could be developed on which the final reports could be shared beforehand. This would save the time of sending, auditing and reviewing thus increasing productivity. 4.5 Invoice Generation Process This process is for the invoice generation for the payment which banks are going to give to IDRBT for using the links for various intra and inter bank applications. The payment is on the basis of the number of links used by each bank. The Invoice generation process is depicted in the flowchart E. The process involves these steps: E1: Banks decides the number of links they are going to use as per their requirement and send this information to the IDRBT. E2: The data about the links used by each bank is prepared by each service provider. E3: Service provider then sends this data to the IDRBT. 17 P a g e

18 E4: As per the information from the banks & its own database, IDRBT identifies the number of links used by each bank. E5: The information/data from the banks, service providers & own database is consolidated and number of links used by bank is identified. E6: This consolidated data is send to the bank for its confirmation. E7: Bank confirms the data about the number of links they are using and send it back to IDRBT, thus confirming the final number of links on which payment invoice is going to be made. E8: Total amount to be paid by bank for using the links is calculated by multiplying the number of links used by bank by amount per annum per link. This amount per annum per link is the particular amount which each bank needs to pay for one link they are using for one year. E9: On the basis of the amount calculated, the invoice is prepared which is sent to the bank for the payment. E10: Payment is being made to the IDRBT from the bank. E11: Payment from the bank is checked for the correctness and its receiving is confirmed. KPIs for Invoice Generation Process Time taken to consolidate the data This is the time taken to consolidate the data about number of links used by bank from bank, service provider and own database. This should be low. Time taken to generate the payment invoice This is the time taken to generate the payment invoice for each bank by calculating the amount on the basis of number of links used by them. Enhancements for Invoice Generation Process Developing common portal A common portal for the banks, service provider and IDRBT could be developed on which the number of links used could be shared. This would save the time of consolidating and confirmation thus increasing productivity. Developing application for generating invoice A small application could be prepared which would automatically calculate the amount for the links used and generate the payment invoice for each bank. This would save a lot of time and make the process more efficient. 18 P a g e

19 4.6 Security Helpdesk Process Security Helpdesk process involves providing IP addresses so that one can access the other secured network. At IDRBT, four levels of secured network are being provided to firewall. Highest secured network is inside, that is, intranet of IDRBT. Next highest is DMZ, then next is INFINET and least secured network is of outside, that is, internet. The department/bank require IP address so that it can access from one network to other network, this is done by Security Helpdesk Team. The Security Helpdesk process is depicted in the flowchart F. The process involves these steps: F1: Security Helpdesk Team receives CRF (Change Request Form) from RBI/other department/bank. This CRF includes request for an IP to have access from one secured network to another. Department send the internal note and banks raise the CRF by /mail. F2: In the CRF, it is seen whether the access is required from high secured network to low secured network or vice-versa. F3: If access is required from high secured network to low secured network, then IP is provided using PAT. PAT is Port Address Translation. PAT permits multiple devices on a local area network (LAN) to be mapped to a single public IP address. The basic goal of PAT is to conserve IP addresses. F4: If access is required from low secured network to high secured network, then IP is provided is using Static NAT (Network Address Translation) or by opening the port. Static NAT is a type of NAT in which a private IP address is mapped to a public IP address, where the public address is always the same IP address (i.e., it has a static address). This allows an internal host, such as a Web server, to have an unregistered (private) IP address and still be reachable over the Internet. F5: After providing Static NAT/opening the port, access-list is checked to see if the IP is present in the access list or not. If IP is not already added, then it is added to the access list. An access list is a list of permissions attached to an object. An access list specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. KPIs for Security Helpdesk Process Time taken to work upon the CRF This is the time taken by the team to receive the CRF and understand & identify the nature of request so as to work upon it. This should be as minimal as possible. Enhancements for Security Helpdesk Process Documentation for requests A proper documentation could be prepared for the common type of requests. This would be useful in understanding and analyzing the requests quickly so as to save the time. 19 P a g e

20 5. BPM TOOLS Business process management (BPM) is a systematic approach to make an organization's workflow more effective, more efficient and more capable of adapting to an ever-changing environment. BPM attempts to improve processes continuously. To incorporate the business processes of INFINET and make it more efficient, BPM Tools were analysed and one of the tools is selected which is best suited to the business processes of INFINET. 5.1 Analysis of various BPM Tools Six BPM tools were analysed to choose the most suitable tool in which business processes of INFINET could be incorporated. The tools analysed were jbpm, Camunda, Activiti, Process Maker, Intalio and Bonita BPM. All these tools are selected for study as they are open source tools and free download from their respective sites. jbpm is a flexible Business Process Management (BPM) Suite. It makes the bridge between business analysts and developers. jbpm has a dual focus: it offers process management features in a way that both business users and developers like it. jbpm supports adaptive and dynamic processes that require flexibility to model complex, real-life situations that cannot easily be described using a rigid process. It requires the knowledge of Java to use jbpm. The camunda BPM platform is a powerful yet lightweight framework for workflow and process execution. The functionality provided by the camunda BPM platform comprises three main aspects - Process Engine, Process Application and Runtime Container Integration. It requires the knowledge of Java, XML, to use this platform. Activiti is a light-weight workflow and Business Process Management (BPM) Platform targeted at business people, developers and system admins. Its core is a super-fast and rock-solid BPMN 2 process engine for Java. This tool requires the good technical knowledge of Java developing. Process Maker has different features for process designers like process map designer, Dynaform Builder, advanced debugger, user management. Less features is a disadvantage of this tool when compared with others. Intalio is designed around the open source Eclipse BPMN Modeler, Apache ODE BPEL engine, and Tempo WS-Human Task service developed by Intalio. It has features like business process modelling, business process design, business activity monitoring, etc. But low user friendliness makes it a less compelling choice. Bonita BPM can be used to automate and optimize business processes. One can design the processes graphically, run the processes, connect the processes to IT systems and can easily manage the processes. It has variety of features like process modeling, connectors, simulations, web forms, installing custom KPIs, creating dashboards, document management, etc. It is a user friendly tool with good features. 20 P a g e

21 After studying all the above BPM tools, it is decided that Bonita BPM is the best choice to incorporate the business processes of INFINET. It has large number of features, user friendliness, easy to download and suits the INFINET business processes. 5.2 About Working of Bonita BPM Using Bonita BPM, we can create and run any process model. We can create the diagram, define the variables, create forms, specify actors, configure the process and run the process to test it. Let us take an example of an Invoice Generation Process. We can start a new diagram by creating a diagram. We will first name a pool as well as diagram to Invoice Generation Process. Then, we can add step by step to create the diagram as we have done while making the flowchart of the process. We can also add a human task in Bonita BPM. This is added when a human intervention is required in the process. In our example, it could be added when amount per link per annum needs to enter into the process. Now, we need to define and add variables also. In this example, variable will be the amount per link per annum in integer format. Similarly, we can add variables in text, date, Boolean, etc format also. These variables could be used to set the conditions in case of a decision gateway. We can create forms also. Form is a collection of widgets, in the forms the variables/widgets which need to be entered by the human could be added and arranged. We can create a form at any step. In our example, a form could be created at the amount per annum per link step where the person would be asked to enter the amount in the form. We can also specify actors. An actor is a placeholder who is going to perform the action in a process. In our example, an employee who is going to enter the amount will be the actor. We can also add an actor filter to specify a particular employee who can perform a particular task. The process can be configured and tested also. In the configuration of process, actor mapping could be done which would map the actor with the person who is actually going to do the job in a real world. Then, test user could be set by giving the name of other person who is a part of that process. Now, the process could be run for testing and could be checked for the correct implementation and incorporation of a process. 21 P a g e

22 CONCLUSION The project incorporates workflow management into the business processes of INFINET. All the six business processes are documented successfully in the form of flowcharts. The detailed description of each process step by step is also provided in the report. The Key Performance Indicators (KPIs) are also identified for each business process and is mentioned in the report. On the basis of KPIs, enhancements are suggested for each process so as to improve the process, increase the productivity, reduce the time taken by the process and introduce the consistency in the process. Business Process Management tools are also studied and among the six tools studied, Bonita BPM tool is selected to best suited to incorporate business processes of INFINET. The basic working and feature of Bonita BPM is also explained in the report. Through this project, efficiency in the business processes of INFINET could be achieved as the automation of the processes could be done by taking flowcharts as the input for automation. More control on the overall process could be achieved as proper documentation of the processes is being done. The report could also be of a great help to the new recruits joining the INFINET. The new recruits would be able to understand the processes more quickly and in an easy manner. The satisfaction level of RBI locations and other member banks would also get increased as process consistency could be achieved which in turn would result into improved quality of service. Overall, business process improvement could be achieved as the main focus is on the business processes of INFINET. 22 P a g e

23 FUTURE PROSPECTS Enhancements suggested in the report could be implemented in real world scenario. The results after the enhancements could be analysed and improvement, if any, could be recorded. The same process could be applied to other SBUs of IDRBT also. In the project report, business process management (BPM) tool is identified. Bonita BPM is selected as the best tool which could incorporate the business processes of INFINET. Bonita BPM tool could be more explored in the future. All the six business processes of INFINET could be implemented on this tool. Using the flowcharts and documentation, the process diagram, configuration and running of process could be done in the future. If the tool is found successful in implementing the business processes of INFINET, it could be applied to the other SBUs of IDBRT like SFMS. The tool, in fact, could be implemented on all the processes of IDRBT so as to make the organization more efficient and productive. 23 P a g e

24 REFERENCES docs.oracle.com/cd/e17984_01/doc.898/e14729/understand_workflow.htm P a g e

25 ANNEXURE FLOWCHART A : Monitoring Process Monitoring Desk Start A1 Monitoring tool sends alert for an issue A2 Router status is checked through logs A3 Has ticket raised by MPLS? No A4 Intimate the MPLS team Yes B A5 Check ICMS for the ticket status A6 Generate reports for all routers A7 Send it for SLA calculation C Close 25 P a g e

26 FLOWCHART B : MPLS Helpdesk Process Banks Service Desk NOC Service Provider Start Start B5 Start B6 Monitoring tools detects issue B1 Monitoring links Banks detects issue Telephone/ /Post Service Desk No Issue detected B2 Start Close Inform banks Yes B7 Ticket already raised? Alert mail sent to service desk B3 Yes Raise ticket with service provider Service Provider Support No B10 B8 Raise ticket Obtain ETR with service provider provided to service desk B4 Update BMC Remedy Close B9 Follow-up Calculate ETR (Estimated Time to Recovery) B13 Resolve Issue B11 Is business impact high? No B14 Update service desk/ NOC Yes Follow-up B12 Check for alternate connection working & inform higher authorities Close B15 Inform bank about status/resolution B16 Update ICMS For RBI issues C B17 Prepare closure reports & send to banks Close 26 P a g e

27 FLOWCHART C : SLA Process IDRBT Service Providers Start C1 Download daily/monthly excel file having reported issues from ICMS Start File provided to IDRBT C2 Reason for Outage(RFO) file is prepared C3 Match Case/Ticket Reference field in RFO with TAC IDs in excel file C8 Final SLA sheet is recieved from IDRBT C4 Combine different fields of RFO & excel file in separate excel file C12 Discussion of downtime to be frozen with IDRBT C5 Final SLA sheet is prepared sent to service provider for discussion Close C6 Final SLA sheet is sent to MPLS team for checking correct entry of all issues C7 Final SLA sheet returns to IDRBT & again reviewed C9 Each issue in SLA sheet is analysed Close No C10 Issue eligible for HCL SLA Discussion on issue & final consensus is made on downtime to be frozen Yes C11 Analysing reason/resolution of an issue C12 Discussion of downtime with service provider C13 Final downtime is frozen D 27 P a g e

28 FLOWCHART D : SLA Payment Process IDRBT Service Provider Start Start Submit to IDRBT D1 Invoice of the particular time period is prepared D2 Final frozen downtime is provided from final SLA sheet D3 Calculation of uptime on basis of final frozen downtime & total time of the service D7 Receives payment from IDRBT Close D4 As per SLA agreement, payment is finalised D5 Internal Note + SLA Amount +Monthly reports send to accounts department Payment being made to service provider D6 Auditors verify the SLA amount D7 Accounts departement releases the payment through EFT Close 28 P a g e

29 FLOWCHART E : Invoice Generation Process Bank IDRBT Service Provider Start Start Start E1 Number of links to be used is decided Information provided to IDRBT E4 No. of links used by bank is identified E2 Data about links used by each bank is prepared E7 Confirmation of links to be used is done Through E5 Consolidate the data from banks, service providers & database of IDRBT E3 Data is provided to IDRBT Send the data to IDRBT E10 Payment is being made E6 Final no. of links are confirmed Consolidated data sent to bank for confirmation Close Close E8 No. of links * Amount per annum per link Invoice sent to bank for payment E8 Amount to be paid by bank is calculated E9 Invoice is prepared Payment made to IDRBT E11 Checking the payment received from bank Close 29 P a g e

30 FLOWCHART F : Security Helpdesk Process Security Helpdesk Team Start F1 Received CRF (change request form) from departments/banks F2 Is CRF required access from high secured network to low secured network Yes F3 Provide IP using PAT No F4 Provide IP using StaticNAT or opening the port F5 Check access-list & add IP if not already added Close 30 P a g e