Any B2B Software is only as Good as Its Users

Working in Product Management for a software is/was the best job I could have ever had, and Thanks to Subex for the tremendous opportunity it had provided me with. RA, FM, CRM, Mobile Money or now GRC (the new domain I am in) et al have a great set of  software tools, which hardly differ in capability, from a great set of reputed vendors who compete among themselves for providing the best of breed solutions for their customers. But… here is the question/situation:

Over time I have seen that these B2B software can be best utilized only when the users completely realize and fully understand what they truly want to achieve with ‘automation’ which is the key underlying capability of most of these solutions.  However that is rarely the case. Most of the software tools are thought to be magic wands that would solve problems just as Harry Potter would create magic with his wand. Everyone says “YES” to the thought ‘Software is Only As Good as Its Users‘ but how many truly implement the concept to the fullest. This is where ROI of the software comes in and there are a great many correct ways in determining the ROI. But I am not sure how much of those are truly used. A number of software providers provide options to sit with their customers and help them make best use of the tool through Customer Advocacy programs; but just because of the tinsy bit of cost associated with it, a lot of enterprises do shrug  away from doing so.

In one of my very recent experiences, I was discussing a potential opportunity for implementation of a GRC system, and in order to understand the business requirements, I had started off with a few probing questions. It was not much of a surprise that I found out, that somewhere deep in the “heart” the expectation was that of a Magic software that would work by itself and get everything done.

Somewhere, someone needs to do the soul-sucking drudgery of populating the system with actual data especially if its a eGRC system, understanding and working out the true business rules required for the business, nail down the “correct” requirements without going into ‘information/data overload’; somebody has to DO all that work, not merely talk about doing that work. Someone has to figure out who is going to ‘bell the cat’ and then make sure they have the time and resources to do it correctly.

So let me ask you three questions:

  1. Do you agree to this problem? If yes, what do you think is/are the biggest impediment/s in full utilization of the software/s at your organization for which millions may have been spent?
  2. How much of the features and functions evaluated during RFPs finally end up getting used?
  3. How much of the work is still done in spreadsheets and offline inspite of the ‘magic’ software that has been bought? Why do you think this is happening?

 

Moinak Banerjee
Moinak Banerjee
Moinak works at Protiviti Kuwait, as Product Lead for their Risk Technology Services. Over the years, he has worked in product management for several leading vendors of telecom OSS/BSS software.

Related Articles

6 COMMENTS

  1. We do not have any expensive software packages in place. We run a project with an external partner which utilizes SQL and linux shell scripts. However, we have SERIOUS issues in getting data – complete, accurate and verified data remains elusive.

    Personally, I see all this data there and am driven up the wall that we cannot have at least a good BI system to present our findings AND provide info and insight. It all comes down to dependable data if you have that then you can do anything – even with no system/tool in place. “Nice to have” tools are not essential but could increase productivity – especially for small RA teams.

  2. I guess an advantage of a tool would be alerts for specific cases that would require more investigation, which when done manually are first of all hard to find, and then require a lot of drilling down to get to the cause.

  3. @ml;
    I must clarify that I am all for automation using sophisticated software. It definitely helps than any form of manual work. However, the best use of the software can be done only when the users know (1)what business problem you are trying to solve, (2) how exactly the software works to solve the problem, (3) what are other benefits that the software brings to the table to aid in the business processes.

    Software as the magic wand of Harry Potter is not an answer for solving any business problems. Even for making the wand work, poor Potter had to memorize a lot of spells. Similarly, users would need to have a grasp of the problem as well as the software to make best use of it so as to make business processes effective.

  4. Agreed. However, it is one thing to know telecoms well, another to know the technology AND another to have a good enough command of BOTH.
    Then you need to know roaming, HLR, billing, sales, read contracts….. its about resources both human and material… I think we agree in any case

  5. Yes, grooming the team to make best utilization of the product is a challenge. This is one of the major factors why telcos are shifting to managed services set up while keeping their focus on core competencies.
    Another thing we’re aware of is the dependency of a downstream application on an upstream system.The subscriber feed, real time credit information, roaming records availability, data errors, log details if not available or are incorrect leads to under utilization of the software features.

    Having worked with more than 15 telcos projects, I feel almost 80-90% of the features which are evaluated during RFPs are utilized at later stage.

    Taking an example of data analytics, everything cannot be clubbed in single software at this point in time. A product company have to maintain their product line too.

    Let me explain this with an example – say Fraud manager gets the cumulative GPRS usage from bill cycle for all those subscribers who have breached their FUP (fair usage policy) limit. A Fraud manager would wish to dig more on this and fetch:

    1) Whether the speed has throttled post breaching FUP limit?
    2) What category/groups these subscribers belong to – bifurcation of these subscriber based on networks they belong to, groups, rate plans
    3) Analysing the usage & figuring out NEW GPRS plan based on high spenders usage? (to be used by marketing team for new product , services launch)

    .. and so on.
    One would thus require clubbing these details with data available in different systems, databases, inventory, etc. Since FMS is a core engine to evaluate the usage records and provide the customer centric report; one must also understand that such integration with other systems is cost dependent. Hence we may still have dependency on other applications – like spreadsheets, comparison tools, dashboards, etc

  6. Hi Moinak,

    I can absolutely relate! During my time as a Senior Pre-Sales for a large software vendor, I also observed how clients often expect a magical solution and end-up totally under-utilizing the functionality available.
    I cannot speak for all software vendors (and it’s been a long time since I’ve lived one of these projects) but I can share my experience from a few years back and the conclusions that I reached then.
    I think that it comes down to the way the software-vendor is approaching the initial implementation project. It’s the greatest missed opportunity in my opinion! At that particular time, the vendor’s constraints make him chose an approach that eludes the chance to make the client embrace the software as an investigation tool.
    Here’s why…
    After a sale is made, the software-vendor wants to implement and reach acceptance as quickly as possible. The least amount of time spent on the project, the more profitable the project is… The project team will therefore have a tendency to take the “shortcut approach” and replicate whatever business-rules the data-mediation system is using, or whatever commonly accepted logic is currently in place. Quickly indeed, you’re getting your KPIs and nice graphs that reconcile pretty well and the acceptance can be discussed. This phase is too often left to technical teams to lead.
    On the other hand, this very first implementation phase should be an opportunity to review all the business-rules currently implemented, to question the obvious and to demonstrate how the tool can be used for that… But this is time-consuming, requires the involvement of a large number of competencies distributed between many departments, not necessarily all mobilized and available at the time of the software implementation.
    At the end of the project, the client is getting his tool delivered with the initial configuration, as agreed per contract. And because of this lack of direct participation by the client to this initial phase, the tool becomes perceived as a monitoring tool more than an investigation tool (explaining the amount of work still going-on with XLS spreadsheets). The client might be trained to expand on this initial configuration but has not necessarily seen the benefits of using the tool to do so, to question the business-rules or perform ad-hoc investigations using the tool.
    Finding a different business-model for these project-implementations and defining the proper acceptance criteria would be my way of having the client embrace more of the software.

    Then you have the sales that are simply the result of a “group-decision”, if the operator belongs to a large international group. Standard group-KPIs have to be produced that way, so for these operators, the tool becomes a somewhat mandated purchase, which easily explains why not all functionality might be adopted.

    In any case, I would love to hear how current implementation projects now differ from these observations.

Comments are closed.

Get Our Weekly Newsletter by Email