I have been sharing thoughts recently with other EAI professionals about putting in place a single portal for all employees of a company; for me this should be the ultimate goal of a company in order to better manage the quality, compliance and employee profitability in the life cycle of every task done in the company.
Why a unique portal?
The concept of having in place a single portal for all tasks in the company will bring a unique turnkey portal site. Having too many applications to look for to do the day to day work can be sometimes overwhelming and switching from one application to another is distracting and make employees lose their focus thus lose time and productivity.
This single portal can also be used to connect to the other legacy systems of the company like accounting, inventory, mail, etc, reducing the total cost of ownership (TCO) of the IT infrastructure.
It can be seen as a catalog of services provided to employees where they will just focus on their core responsibilities while not worrying about where it has come from and to whom it will be given after; the only point they will need to focus on is that the tasks they are working on is due in some specific period of time and it will ultimately serve a customer (inside or outside).
Doing this they will be able to focus on productivity rather than everything else that is turning it down. We can compare this, during the earlier economy of mass production, to the belt system of production or assembly-line work, when the factories had a perfectly defined process where everyone knew exactly his role and did not worry about who is taking over after him; he only knew that in the end the deliverable will be a car, a drawer, a bag, etc.
How can someone build such a portal?
We know that in today’s companies are built on technology systems: each company has various type of systems to manage their GL, inventory, purchasing, suppliers selection, risk assessments, customer servicing, etc; and this create a bundle of applications for each employee to perform one task.
We know that SOA has brought a new vision on how all these systems/applications can be leveraged to provide greater values and fast ways to deploy new services; but as it is now users still have to switch from one application to another to deliver the results of their tasks.
In order to help companies reduce their turn-around time for service delivery, increase their profitability and reduce the cost of their IT systems (licenses and hardware where possible of course), one could build this kind of portal.
Following my discussions with those professionals, stated earlier, this can be done in several ways.
One of them has considered using an MDM-like portal (MDM, which stands for Master Data Management for those who don’t know, is already a part of the SOA stack). From his perspective, MDM and IdM (Identity Management) should not be integrated in a BPMS implementation since they are not part of the main process stream and also as they are provided with a portal, they can be used as the said catalog.
Another one did not agree at all with the MDM portal but was advising that any BPM implementation that quits at documenting and improving the processes will need another platform to manage those processes; thus the possibility of having multiple systems will come up again which will not suit the goal.
Both of them think that having the unique platform as a unique portal for a company is achievable via a catalog but not through a BPMS for large organizations (maybe some medium ones).
Well I do believe that it can be achieved…
BPMS: the single portal
From my perspective, when we take BPM as the operating methodology of a company, it can achieve highly controlled and understood environments in its different areas and this is before even talking of implementing the automation aspects of it.
After the BPM methodology is fully understood and being implemented in the company, the deployment of a BPMS will happen and this deployment needs to be well designed for it to reach the goal stated above.
First, the company will have to do the inventory of all its processes (done usually at the time BPM implementation) and add to it the systems used in all those processes, once this has been obtained.
They will need to do the inventory of all automation possibilities in each task (user to application, application to application, application to user); with this inventory they can determine whether or not a interaction can be fully automated in the two interaction fields where a user is involved.
Then we will get the complete process from user’s perspective and systems perspective; and as we know most of the BPMS do have connectors to web services, databases, legacy systems through Web Services, XML, Messaging Services, it will be possible to built the defined processes and automate the interactions with other legacy systems.
This will then lead us to a BPMS as a single portal to say not all but at least 80-90% of users of a company.
Depending on the maturity level and size of the companies, this can be a long run for companies and some may not feel the need to put such an effort on this, some other might be able to cover half of their processes using this architecture. But I do think that it can be a long term goal which once achieve can bring higher benefits.
For SMBs or start-ups, it should be a must to start or move to this architecture… But these are my simple thoughts, please share your own.