BPM-EAI

Well I couldn't resist taking reference from a previous post by Arun in framing the title of my post. Well quite a few years back entire tax filing procedure would have felt like taming that giant reptile (now extinct though).

Business-Process-Management, is a philosophy, an approach, a management discipline etc etc. No, I won't be touching upon the basics (or not so basics) of BPM in this post. What I intend to do with the help of this post is to sensitize you to the amazing yet complex world of tax (and whether or not, we can use the principles of BPM to resolve certain issues that certain tax-payers face). You can love (nobody does so though), you can hate but you cannot ignore taxes.

Before, our honorable Finance minister, tries to make things a little less complicated by rolling out GST, I decided to tread upon, not-so-favored and not-so-glamorous topic of process of tax filing.

Tax return filing as a process, I remember, used to be a bit on a cumbersome side. With whole set of documents in the shape of forms (SARAL- ITR form), to be filled and attaching supporting documents and making a queue to file returns at local Income tax office or designated booths or hiring agents who can do the same for you, for a certain fee. Now with the advent of e-filing and subsequent simplification of form, you just don't need to be a part of the queue. Everything could be done at comfort of your office desk or living room sofa. This certainly is a case wherein a process has been re-engineered to suit the interest of common man. Although I do not have stats to prove, but in my opinion E-filing would have definitely helped more people to be tax-return-filing-compliant, if I am allowed to put it that way.

Alright, with this small primer, I would like to touch upon other areas in this domain wherein BPM could be leveraged to simplify the process. Since, we would appreciate that scope is huge; I would restrict myself to one particular area of taxation viz. Service tax. To get an overview of this, feel free to visit Service Tax page maintained by Central Board of Excise and Customs.  To give you a brief, the concept of Service Tax came into force w.e.f. 01-07-1994 with just 3 services and rate of 5% to begin with. Right now the net has been widened to cover more than 100 services and effective rate (including Education Cess @ 2% + Secondary and Higher Secondary Education cess @ 1 %) comes out to be 10.3 %.

Without further ado, let's concentrate on the process aspect of service tax filing. If I am a service provider, let me enumerate the various stages to go through to comply with the rule books.

Registration:
Every service provider of a taxable service is required to register with the jurisdictional Central Excise Office. A registered service provider is referred to as an assessee. Service tax is administered by CBEC (Central Board of Excise and Customs). You have to fill form ST-1 in duplicate and submit the same with a copy of PAN Card and Address Proof. Afterwards, you need to collect your registration certificate.

Before I go into the process of Service tax filing, let's understand certain general procedures.

Every person providing taxable service is required to issue (within 14 days of completion of service) an invoice or a bill or a challan duly signed by him / her or a person suitably authorized. Such invoice, bill or challan should follow certain standard and contain certain set of information.

Similarly, every input service distributor, distributing credit of taxable services should issue an invoice, a bill or challan signed by him or her or a person suitably authorized for each of the recipient to whom credit was distributed and such invoice, bill or challan as in earlier case should follow certain standard and contain certain set of information.

Service Tax Payment:
As per Government of India Service tax website:

1. In case of Individuals or Proprietary Concerns and Partnership Firm, service tax is to be paid on quarterly basis. The due date for payment of service tax is the 5th of the month immediately following the respective quarter. For the purpose, quarters are: April to June, July to September, October to December and January to March. However, payment for the last quarter i.e. January to March is required to be made by 31st of March itself.
   (Refer Rule 6 (1) of Service Tax Rules, 1994)
2. In case of any other category of service provider than specified in 1 above, service tax is to be paid on monthly basis, by the 5th of the following month.  However, payment for the month of March is required to be made by 31st of March itself.      
   (Refer Rule 6 (1) of Service Tax Rules, 1994)

Returns:
As per Government of India Service tax website:

1. Every assessee is required to submit a half yearly return in form S.T.3 or S.T.3A (in triplicate) along with copies of T.R.6 challans. For the purpose of filing returns half year is counted from April to September and October to March. In case the assessee has opted for provisional payment of service tax he is required to file the service tax return in form S.T.3A. (Rule 7(1) of Service Tax Rules, 1994)
2. Date of filing of Returns: The half yearly return is required to be filed by the 25th of the month following a particular half year. (Rule 7(2) of Service Tax Rules, 1994)

Although, similar to Individual Income tax returns filing, we have an option to e-file return as well.

So in a nutshell the process is like:

Alright, so as a process, a cake walk for process analysts. Or is it?

Let me go into the certain fine prints of this process. Take a fictitious case of a tower firm operating in NCR (National Capital region) including Gurgaon, Noida and Delhi, which is in the business of erecting towers for Mobile companies, Power companies etc. Now where does it need to file challans and returns and what would be the appropriate rate of tax. This would fall under works-contract where in Service tax is charged at 4 % of contract value under composition scheme.

Now regarding location of filing, it has to be done in 3 state jurisdictions since Gurgaon happens to be in Haryana, Noida in U.P. and Delhi is a separate jurisdiction. So every time, the process has to be repeated 3 times at 3 different jurisdictions.

Now where would a typical BPM solution fit in this scenario?

• Since tax rates are nothing but rules which need not be tampered on a daily basis or even monthly / quarterly basis, these can be made a part of the rules engine and accordingly updated as and when there is a change.
  
• Most of the forms are pretty standard and can be prefilled fetching from legacy data. That is the system would generate a signature ready tax return or a challans for that matter. This would greatly reduce time and cost overheads.
  
• Document management system would ensure that there is a copy of each and every transaction invoice as well as challans and returns. This would be of great help during the time of audits.
  
• Report generation facility could be used to analyse tax behavior of the organization.
  

In the era of scams and malpractice, where with each passing day regulatory authority is tightening the noose, the onus lies with the companies to comply with the laws of the nation and tax compliance is definitely one of those.

Can BPM deliver or not or will people ask for it, is definitely a question to think over.
Feedback, comments and suggestions are most welcome.

Posted by Arup Guha at 12:22 PM | Permalink | Comments (2) | TrackBacks (0)

I am not too sure about the title, but I had to enter a title to share my thoughts. And this is the best I could think at this point.

Now coming to the question, which I was asked few weeks back

"Company X has decided to go for SaaS based applications to run its enterprise and are not sure how to get control over these applications which are scattered over different clouds"..

It is an interesting situation which was never an issue in a typical on-premise deployment.

However when any organization chooses to go for SaaS based deployment, I would believe that organization has implicitly decided to let go the control over application and the data architecture which drives application behavior. This means the real issue that organization is facing is

"How can Organization's IT ensures that SaaS based applications can consistently deliver to the business goal if they have no control over these application architecture which are providing services to their business directly"

Let us analyze the situation with a perspective

Company X has gone for these SaaS applications for different specialize functional areas for example a SaaS based application for CRM, Product Management (which includes pricing), eCommerce (Ordering), Order Management, Billing and After Sales Support. Considering each of these functional areas is specialized area it made perfect sense for Company X to go for different SaaS offering for each of their functional areas. I think this holds good for COTS based strategy too for on-premise deployment.

And at the same time there are customer facing end to end processes (for both on-premise and SaaS deployment) like "Prospect To Cash" which are customer touch point based process which make use of services from each functional area to meet customer need. These are sometimes are referred as Operational processes.

Now the question is how does organization manage these when nothing is on-premise?

In my view to manage this, IT should align itself to business to manage its Key performance indicators (KPI) rather than focusing on application architecture.

Either in an on-premise deployment or SaaS based deployment these functional and operational process areas are typically governed by Functional and Operational KPIs, which IT should provide as Management Information dashboard to business.

Example of a Functional KPIs is for product management functional area is "time to market" of new products or "number of product variance introduced". And similarly example of operational KPI is "cycle time" for "Prospect to Cash" process.

Hence for a SaaS based deployment where the application architecture control is minimal it is important for organization to have clarity on the functional and operational KPI based on business goals and manage these set of SaaS applications through these KPI's. To do this the key elements that organization should have in place are

• High-level Process views for both functional and operational process (typically till L2 level)
• Business Goals broken down to Business KPI and aligned to each functional and operational process areas
• Enterprise Data models which would drive 
• Operational data stores to create management information report for the established KPI
• Data acquisition from each SaaS application with appropriate mapping to create accurate report
• Standardized data payload definition for Service based integration of each functional to realize a smooth integration required for end to end operational process
• A common integration platform that should provide the integration fabric required for realizing the end to end process. Which in turn should be utilized to create the BAM view for the end to end operational process
• And at the end a BAM view over the functional Process to manage the process performance within each functional area. For which Organization should demand the real time KPI view from the SaaS vendors

However for SaaS based deployment data security should be the foremost concern that organization should address first and then look at the KPI based approach to manage the SaaS application landscape.

Posted by Manas Kumar Sarkar at 10:55 AM | Permalink | Comments (2) | TrackBacks (0)

Imagine you are seated in a class room. The blackboard reads ‘Aerodynamics 101’. The lecturer is a elderly bespectacled gentleman with an air of excitement about him. As he welcomes you to his course, he shares that he is about to illustrate the mechanics of flight. On his table you notice an over-sized model of an aeroplane.

Barely containing your excitement, you open your notebook eager to make notes. The lecturer proceeds to point to different parts of the plane and explains what they do. He goes into fair bit of detail about the aerodynamic characteristics of each such as mass, turbulence etc. After this fairly lengthy exposition, he completes describing the last part of the model aeroplane’s anatomy and concludes that by now you must be having a fairly good understanding of aerodynamics. Before you open your mouth in protest, the bell rings indicating the end of the allotted time for the class.

Before you wonder, how such a class can be of any benefit at all to a student of Aerodynamics, notice that this analogy is perfectly applicable to Technical Documentation. Most of the time a code base is handed over with documentation that describes in a fair bit of detail about its various moving (and non-moving) parts. There is considerable amount of information lacking about how the system came to be what it looks like today.

Any sufficiently complicated system is a result of many design decisions, trade-offs and optimisations. The complexity cannot be appreciated unless we describe the reasons that led the creators to such decisions. This provides the vital aspect of Context to the system we have at hand.

A typical system’s documentation is spread over several documents such as Design documents, Technical specifications, User manuals to even the code and unit-tests themselves. Barring a few exceptions, these documents would talk about the end-state the system is in today. Perhaps, digging through the version control system might provide some insights, but generally the Context is buried for convenience.

This leads several serious problems ranging from duplication of effort to even failed integration efforts. At one of our banking clients, we once tried to implement an ambitious initiative i.e. a project to add sequencing to all internal intra-company messages. This involved wrapping a header around the existing messages which would now be called payload. The header would contain timestamps and serial numbers which would help in resolving the correct sequence (for the uninitiated, this is actually a pretty hard problem).

Half way into design we realised that the existing messages did contain a fairly unused field named UID. It was, in fact, derived from the message creation timestamp. They appeared in a strange but a deterministic sequence. This was previously considered to be a randomly generated number! Not only was the entire exercise scrapped, we gained smadmiration for the designers of the legacy system.

What’s the real test of good documentation?

We all fall into the trap of Documenting the Dinosaur. Without understanding the evolutionary steps behind the creature, it would be impossible to appreciate its current form. Of course, the best way to resolve this is to compress all the historical decision points into the design documents. In fact, some document authors actually do this.

But this is a laborious exercise. There are various other means to verify the effectiveness of the documentation:

• Extensibility: How easily can one integrate with the existing system? How many times have such attempts failed?
• Sustenance: How actively are the documents maintained? How much of context is carried over when a change is implemented?
• Ownership: Are the designers/developers/users of the system in joint ownership of the documents? If the documentation work is performed by a separate team, are there means to avoid it?
• Collaboration: How easy is it to view and change the documentation? Is it open for public review?

A positive answers to these key questions can prove to a critical checklist to your documentation. At worst, it may be a bit of additional work, but it can certainly prevent your system go the way of the Dinosaur!

Posted by Arun Ravindran at 11:47 AM | Permalink | Comments (0) | TrackBacks (0)

Guest Post by Dr. Setrag Khoshafian, Vice President of Product Marketing and BPM Technology at Pegasystems Inc. Dr. Setrag regularly blogs on topics related to BPM, BRE/DM, CRM, Case Management, and Risk/Fraud/Compliance through BPM.

We often hear the motto, “What gets measured gets done.” The “measures” could be simple and tactical, such as the average time it takes to resolve a customer claim, or the maximum cost of opening an account. Measures could also be strategic and critical such as the what is happening with US public debt. We have been hearing a lot recently about president Obama’s special deficit commission to come up with practical solution for the ever-increasing US debt - which is now in excess of $13 trillion.

It will be a challenge. It is not easy to improve all measurements. Sometimes the initiatives to keep the measures in control are too complex and take too long to improve. Actions to remedy measured performance indicators could be marred in bureaucracy and stakeholders sometimes lack the will to make difficult decisions. So how can we link measures to actions?

The synergy between two complementary disciplines exemplifies the linkage between business measurement and action (the “gets done” part): BI and BPM.

Business intelligence (BI) focuses on gaining insight or knowledge from data. There are many sources of data, including the following:

• Operational or transactional data from legacy, point-solution, or ERP applications;
• Process instance and case data from BPM suites;
• Data from external sources including, but not limited to, public and census data;
• Data warehouses and/or data marts that aggregate databases (mostly relational) from a plethora of sources, including transactional, operational, or BPM databases.

BPM focuses on execution and automation. BPM allows monitoring all the events and activities of automated processes. Reporting on work assignments and providing reports as well as analysis of automated processes are important Business Activity Monitoring (BAM) capabilities within a BPM suite. Examples of generic business activity monitoring reports here include the performance of operators, teams, and organizations; reports on activation, progress, and completion of cases; time series on process creation or completion over a time interval; etc. In BPM Suites BAM reports are graphical and actionable: managers, for instance, can interact with the report and decide to re-assign tasks. In fact, BPM has the potential of linking both strategic as well as tactical measures to process activities.

The continuous measurement and performance-based cycle gets completed when we tie BI approaches and techniques with BPM. In a recent episode of the BPM Professor, I expanded upon the relationship between BPM and BI. There is a spectrum of measurement and mining techniques, from simple reports to advanced predictive models. Furthermore, as noted above, data can be obtained from a plethora of sources. Data mining, and especially predictive modeling techniques, can be used to detect business patterns and then invoke the discovered rules in the context of BPM solutions. This is the essence of Predictive BPM.

Through automated BPM solutions, BI becomes “operationalized.” This means insight that is gained through reports, analysis, or discovered patterns through BI tools, could be acted upon through BPM solutions. BPM involves operators and the end-to-end control of the processes. The “doing” - or escalations and actions - are not left to chance. The service levels that specify the requirements of due dates are automatically resolved or escalated. The operators are guided and assisted in their user interactions. The measures and the actions get coalesced: merging insight from historic as well as real-time data with actions in the context of automated processes.

So with BPM using the best BI techniques and disciplines, what gets measured perhaps stands the best chance to get done. But not always. Probably not for complex and strategic measures such as the national debt. Nevertheless, it still stands the best chance to get done!

Posted by Dr. Setrag Khoshafian at 6:31 AM | Permalink | Comments (1) | TrackBacks (0)

I woke up this morning to a grumbling neighbor whose power had been cut-off citing non-payment of his electricity bills. Turns out his electricity meter had stopped functioning for over two months, and his repeated letters and e-mails sent to the local electricity department to intimate them of this situation had been over-looked. But with hundreds of complaints pouring in, thousands of consumers rushing to pay on the very last days of the deadline and the innumerable administrative issues that haunt the employees - such mistakes on the part of these officials seem, more often than not, predictable.

I went back to my desk later, curious to see just how large the customer base for the country's electricity board would be. Turns out - it's at least (a whopping) 144 million customers across India; likely to be about twice the population of a country like the United Kingdom!

The administrative and organizational set-ups for such boards involving either services or legislation are growing increasingly complex. But, whether it is the electricity board or the judiciary system, what can be taken advantage of in such situations seems to be the fact that the magnanimity is under-lined by specific fundamental processes which are usually common across the consortium of these boards and branches. 

So I'm just thinking aloud here....
If this were to be mapped into the world of proactive BPM - the key to efficient and consistent services would begin at first gaining the ability to clearly define and map these root processes across various functions carried out by these boards. While this exercise is executed, the order of the day would also be to look out for process patterns or functions that are generic in nature. These processes are pulled out and refined in a manner that could automatically add to the overall process efficiency.  The focus would also be on translating them into more flexible and intuitive processes.
Arguably, the strongest ability of BPM would lie in the conversion of experience into tangible action. Using BPM, concepts like the rules engine could be put in place to clearly demarcate the rules that drive each process from the process as a whole. This could mean for instance (in a macro perspective), that some of the governments frequent policy changes could be applied across the board with only a few changes in the rules that apply to the application.

So a very generic example could look like the one in the image below (the diagram looks at very basic examples of processes that exist under any power cooperation).  The processes in total could be sub divided into four or five layers beginning at the Core processes and trickling down into various levels of Sub processes. The segregated processes could be stored in a process repository to be accessed by the various electricity boards in the country, for example. The process orchestration could be done on a BPM platform while say an Enterprise Service bus could be used to allow the various services to be accessed. So while the processing logic is moved into a separate library, it could also be accessed as a service through the ESB.

However, what side would the odds be on when one looks at modernizing a system built on layers of complexity? Given the nature of public sector units many of the processes involved would depend heavily on government legislations. Also, with tens of thousands of employees many of who have been in the existing system for over a decade or two? 

If you've been a part of similar implementations do chip in your experience and how you went about restructuring the system!

Posted by Priyadharshini Vijayan at 5:09 AM | Permalink | Comments (0) | TrackBacks (0)

In a fictional drama based on characters of the great epic Mahabharatha, a Telugu poet/dramatist Mr. Chilakamarthi Lakshmi Narasimham, talks of a great war, which was averted at the last moment due to intervention of Gods. The story goes this way Gaya, a Gandharva King (Gandharvas can be considered “being of heaven”) was moving across the skies and spat the pan. It fell into the open palms of Sri Krishna (An Avatar of Lord Vishnu), praying to the sun god Surya. Sri Krishna gets very angry and vows to kill him. Then the Gandharva king, being a great devotee of Krishna, begs him for mercy and Krishna doesn’t concede.

Narada (Son of Lord Bramha, a divine sage) advises Gaya to approach Arjuna (one of the Pandava brothers of epic Mahabharatha) and first seek his assurance of protecting him and only then reveal the name of person out to take his life. The king does the same and after taking Arjuna’s promise to protect him, he reveals that Krishna has set out to kill him. Arjuna is surprised and yet sticks to his vow. It might be noted that the friendship and relation between Arjuna and Krishna is supposed to that of ideal relation between Nara (human) and Narayana (God).

Any number of dialogues between Arjuna and Krishna make no dent to their respective vows, Arjuna to protect Gaya and Krishna’s to kill Gaya, resulting in an impending war between the both. Those days, unlike now, word given by self was considered paramount than life of self.

Almost when they are out for a head on collision, Lord Siva (an important Hindu Deity, and one of the Trinity) appears before them and averts a possible disaster to the world. This is later explained by the Lord Krishna as a test for Arjuna before the impending Mahabharata war. [For details about Mahabharatha etc. please Google.]

Though the preceding is a drama, a fiction, it shows the lock-in of the people about the words they give. Isn’t it similar to the vendor lock-in. Once an Enterprise goes to a vendor, they are locked-in, with no way out.

For any Enterprise IT, there are three layers, which form the IT stack, starting with Hardware (H/W), Operating System (OS), Applications (Apps); along with “Services” for these layers in form of Infrastructure Support and ADM.

1. The first such vendors to provide single stop shop (Single Window) for all Enterprise IT layers’ needs was/is IBM, with their H/W, OS and Apps along with their own consulting unit (GCS), which can take care of the “Services”.
2. With the acquisition of Sun, Oracle too now has H/W, OS, Apps and “Services” via acquisition of I-flex, Hexaware and their own consulting division et al.
3. Microsoft has a long relation with Intel to the extent that WinTel is known moniker in the Enterprise world. Together, they form a formidable force, with many regional “Service” providers.
4. SAP has it’s own Apps and “Services” and for sake of OS they “might” acquire Novell or Redhat, get into a tie up with HP for H/W thus completing their “Single Window”.

Any lock-in has its merits and also comes with its baggage of limitations. The merit being, Management can delegate all the needs to the Enterprise IT to the “vendor” and take care of their primary business that of serving their customers.

A case in point is Bharathi Airtel of India (a large Telecom provider of India), where the Enterprise IT is handled by IBM, the networking needs are handled by Alcatel and Siemens, which the management just focuses on the needs of their customers. Their customer share of Indian mobile/telecom market is around 61%. (Market share source Internet)

The limitation is that the CIO does not get the best of the breed, like she cannot cherry pick from each of the vendor based on the needs of organization. If a vendor is good in one area of specialization and not so good in another area, they need to live that as they are locked in.

How to avoid the stalemate, would give us two solutions.

*One *- going the cloud way, where the applications are never owned, but rented. H/W, OS and “Services” are minimal as in an ideal Cloud world, “Internet would be the Computer” and the device used would be more or less like an erstwhile “dumb terminal”. As a by-line to this, the device that goes around today as a “smart phone” is less of a phone and more of the step towards Cloud. Most of these “smart phones” are used more for accessing the “applications” over Internet than for making the voice calls, more for sending “messages” and “mails” than having a “small talk”.

There is a catch in this approach, not all the applications are “Cloud Ready”, however as a first step towards “Cloud Way” the social networking applications have their “Apps” on these devices. In near future we may all be using devices with have just network capabilities with little or no OS, H/W from a vendor neutral supplier, but capability to download the “real” OS and the “Enterprise Application” that the user plans to use. Then Google/Amazon/Gen-Z-Co would be the rivals, with the traditional players in the Enterprise IT World being the second rung players, unless they sit up and look into the approaching thunder storm as clouds are already visible on the horizon.

*Two *- Till the time, we get into tomorrow’s Cloud, we can still have best of breed with CIO cherry-picking the application from different vendors for this Enterprise. We can integrate them to work as a seamless engine to support the business drivers of the Enterprise.

This is where we at Infosys can come into picture, to help you reach tomorrow by paving way today. For more information about Infosys’s plans for “Building Tomorrow’s Enterprise” please take a quick look at our Annual Report.

Posted by Anil Prasad Kurnool at 6:24 AM | Permalink | Comments (0) | TrackBacks (0)