 Abstract: The success of any IT initiative could be measured in terms of the actual business goals that it fulfills. However, when it comes to SOA based projects, it becomes imperative that such an initiative bears close correspondence with the business requirements as SOA is usually an enterprise wide activity, so any slight deviation from the actual business goals could result in an SOA that is misaligned with the enterprise wide goals. So in order to achieve this required alignment, it stands necessary that before starting off with the service-oriented analysis phase, a high level view of required SOA needs to be in place that ensures that the subsequent analysis phase concentrates on business processes in the order of their preference with respect to the business goals linked with each business process. Business Process Analysis (BPA) offers matrices that help in drawing a correspondence between business goals and high level services. BPA also helps in prioritizing the business processes in terms of the most pressing needs of an organization. This article presents the rationale for BPA, its importance and more importantly it describes the actual steps involved within BPA with the help of a case study. Introduction The importance of BPA within traditional application development accounts for a successful end product that is more aligned with the business requirements. However, within an SOA, being inherently an enterprise wide initiative, the requirement for conducting BPA becomes more prominent and warrants an individual development activity on its own unlike a traditional SDLC where it is more embedded within the analysis phase. The basic tenet of SOA is to align IT with the business processes; consequently BPA's rationale is to align SOA with the true business needs so that the services created at the end of the SOA development process fulfill the actual business requirements. BPA helps focusing SOA initiative on the set of business processes whose automation would address the most pressing requirements of an organization. It helps in drawing a one to one correspondence between the business goals and the required services. Without a BPA, there is a strong possibility of SOA's development efforts to be focusing on issues that although need addressing but are not an organization's priority, thereby not bearing the required results. Unlike traditional software development, where analysis could be performed by following an established set of techniques (e.g. use-case analysis, data flow diagrams, ERDs), SOA requires a discrete set of business analysis activities that establish the baseline for the actual service-oriented analysis & design. Organizations are always faced with the classic dilemma of scarce development resources in order to address ever growing list of business requirements. Consequently for an SOA, that already faces opposition from the traditional software development hardliners, these scarce resources need to be focused towards addressing the actual business requirements starting with the most important ones. This focused development is only possible when one can justify the required services by drawing a one to one correspondence between the business processes and a set of high level services. BPA helps to draw this correspondence and thereby guides the SOA development efforts towards the creation of services that actually address the business requirements. One of the misconceptions about SOA includes the presumption that the SOA follows the big-bang theory as a result of which architects try to service-orient every other process without prioritizing them according to the needs of the business requirements. Those that have followed this route already know the consequences when it comes to reviewing the fulfillment of business requirements from the first set of developed services. However, all this could easily be avoided by performing a Value Chain Analysis that prioritizes the business processes in terms of their importance to the business. Although the techniques presented here do not constitute a complete set of steps involved within business process analysis by any means, however, these do help in providing a basis for such an analysis. These techniques have been described by using a case-study as an example as it helps to draw a better understanding of the actual process. Case Study: Carry On Calling Carry On Calling (COC) is a UK based company that provides post-paid mobile connections with subsidized line rent. It acts on behalf of major mobile phone network providers and works on a commission basis. It subsidizes the line rent by giving cash-back to its customers. Customers can get a connection directly from the network providers, however, what makes COC's deals appealing is the fact that not only does it provide subsidized connections but also provides free handsets to its customers. Although it started off as a small company, because of its low cost deals, its customer base is growing exponentially resulting in quick expansion of the company. This quick expansion means increased profits but at the same time it brings along a plethora of problems which are hindering company's productivity as well as its targeted growth. What COC offers to its customers is a post-paid phone contract including free cross-network minutes. COC combines the contract with a specific handset and presents it to prospective customers in the form of a deal. Various deals are available to its customers having different combination of free minutes and handsets. The net profit earned by COC is calculated by deducting handset's price, which COC purchases from various handset suppliers, from the commission earned. Although the commission provided by the network providers seldom change, it is the price of handsets that changes quite frequently mainly owing to the introduction of new handsets every other month. Other companies are joining the same line of business that get the same percentage of commission from the network providers. So to remain profitable, this puts the entire burden on finding the cheapest handset and then combining it with the most favorable contract in order to make the deal an attractive offer. This requires real time information regarding the commission offered and the price of handsets. Current State of Affairs The company's main business processes are as follows: Contract Acquisition Process A prospective customer gets information about current deals over the telephone or in person. If interested the customer fills in a form that includes name, address details of the past three years, the chosen package and the bank details. If the customer has contacted via telephone, then he is informed by the sales agent that he would be contacted back shortly, however, if in person the customer is asked to wait. The sales agent validates the form and if all the details are correct, the details are forwarded to the relevant network provider (depending upon the chosen package) over the telephone by the agent. While the agent waits over the telephone, the network provider processes the application and informs the agent of the outcome. The outcome could be (a) accepted or (b) rejected. The prospective customer is informed of the decision. If accepted, customer account is created in a client-server based sales application, a handset is allocated, then the customer signs the contract (form) and is given (sent in case of telephone enquiry) the handset, contract details are sent to the relevant network provider and the details from the form are entered in the sales application. In case of (b), the prospective customer is simply informed of the decision. In both cases, the form gets filed at the end. Where the application is made over the phone, in case the application is successful, the contract is sent to the customer by post for his signature and is filed once received back. In case of a successful application, a request is sent to the accounts department to open customer's account in the accounts module of the Enterprise Resource Planning (ERP) system. Cash-Back Process Each month, upon receiving the telephone bill from the network provider, the customer sends a photocopy of the bill to COC. When received by COC, this gets recorded against the customer account in the accounts module of the ERP system for that particular month. COC takes two weeks to send the cash-back to the customer through bank transfer. On the other hand, the network provider deducts the billed amount through direct debit each month. Commission Claim Process An invoice, consisting of the owed commission, is first created within the sales module of the ERP system for the past fourteen days and then sent twice a month to the network providers via email. This gets reconciled by the network provider and if there are no discrepancies between the invoiced amount and the network provider's records, the invoiced amount is credited to COC through bank transfer. However, in case of discrepancies, there is an exchange of emails between COC and the network provider until the matter gets resolved. Stock Management Each month a price list is sent by different handset suppliers to COC. These price lists and the current deals get reviewed manually by the manager. A profit analysis, including different combinations of deals and handsets, provide basis for ordering different handsets. A purchase order (PO) is created within the ERP system and is sent to the supplier via email. The supplier sends an advanced shipping notice (ASN) stating the estimated delivery date . Once received, the delivery note is filed and the stock is manually updated within the stock management system (ERP). The stock is followed by an invoice from the supplier. The invoice is paid subsequently by COC, relevant journal postings are made and the supplier's account is updated within the accounts module of the ERP system. In case the supplier cannot fulfill the order, same PO is sent to a different supplier and the whole process is repeated. Deals Management Network providers send details of their packages. These packages include details such as free minutes, free sms, contract length, validity of the package, line rent, commission and the length of the contract. The manager reviews these packages along with the price of handsets from the price lists. New deals are created or existing ones are updated after performing a profitability analysis. Once created/updated, the sales agents are informed of these deals. Currently the deals are managed using hard copies of packages and price lists. Business Issues In the near future, network providers would cease to support manual processing for: • Contract Acquisition • Claiming Commission The new automated processes need to incorporate electronic exchange of XML documents (contracts and invoices) based on schemas specified by the network providers. New regulations have been imposed by the network providers. This requires keeping track of customers' history so that: • A declined customer should not be able to re-apply within 3 months. • A customer already having a contract is unable to apply for another one. No real time information about the price lists from various handset suppliers is available at the moment. As a result of this, new deals are created without knowing if the current price list is the latest one or not, which can decrease profit margins if the same handset is available cheaply from another supplier. A contributing factor to this inefficiency is that fact that currently the import of price lists is done through a slow and error-prone manual keying-in process into the ERP system. The stock ordering process is inefficient and cumbersome. Current manual process involves looking at existing stock levels and the commission offered on different contracts (which requires accessing two systems at the same time), from this the best package is worked out and a PO is sent via email to the supplier offering the cheapest price (price lists are viewed using the ERP in order to find the cheapest supplier). Once the stock is ordered, the ordered quantity has to be manually updated in the inventory control system within the ERP system. Creation of new attractive and cheaper packages is a time consuming task as no real time information is available regarding the commission offered on different types of contracts and the prices of handsets from various suppliers. Contrary to this, competitors have employed automated systems (that present all the required information as a single view) because of which they can come up with cheaper deals in less time, thereby gaining competitive edge. Allocation of handset is cumbersome. During the final stage of contract processing, once an application is successful, the simple process of allocating a handset requires logging into the ERP system, checking the stock level and then posting a journal transaction in order to decrease the stock quantity and to keep the accounts balanced. All of this overhead not only contributes towards the inefficiency of the contract acquisition process but also stands in the way of fully automating the process. Business Goals
Goal Service Analysis The aim of Goal Service Analysis is to create a matrix (Table 1) which maps business goals to the required high level services that are identified from the processing steps involved during the execution of each business. This technique is based on work done by Pulier and Taylor [REF-1] and Arsanjani [REF-2] in the area of business process modeling. By listing the intended users of these services, security requirements and processing needs of these services could also be derived. A service only to be used in-house would usually require less stringent security requirements as compared to the one accessed from outside. This can also help in determining the communication format of the service e.g. in case of using .NET, the in-house services could be built using the binary protocol (net.tcp) instead of using the ws-http protocol in a bid to make service communication more efficient. Similarly, in terms of processing load, the in-house services could be hosted on a shared server as compared to inter-company services that could be hosted on dedicated servers. It is important to keep into perspective that the processing steps stated against each business goal do not necessarily constitute a complete business process i.e. each business goal might require processing steps borrowed from more than one business process. This implicitly backs up the modular nature of SOA where by the intent is not to build a full fledge system rather the actual building blocks that are reusable among more than one business process.
|
