By: Ivor Bakša, CEO
There are companies which offer complete BSS solution and recommend going with a big bang – full-scale change of your BSS stack. Even if full scale migration is successful, what would be the effort given into project, both money and time wise? Our experience…
Let us imagine the following scenario. One day you wake up and make a serious decision of becoming a better person. Your personal transformation. You set up a goal that in one or two years of preparation you will become the best version of yourself. You set up the exact day when you will become a new person, you read all the books and watch videos about a healthy diet, exercising, meditation, about what being a good parent, husband and friend means and you continue to do so for two years in a row. You create a perfect daily schedule for the new transformed you. What happens on that day (in two years) when you start being a better person? Nothing much, as you did not manage to transform one single small thing which would make you a bit better. Transformation is a learning and experimentation process, and you can learn only by start doing it. Similarly, transforming your BSS or part of your IT landscape is a constant iterative process, it is not something that will happen on the exact deployment date with the sound of the Big Bang and result in an ideal IT landscape that will transform your business.
1) Make a clear architectural picture
Make a clear architectural picture of your IT landscape with systems and their modules. This is a
starting point. This figure could save you a lot of time for future meetings, RFP or projects you
have with the potential new vendor, some other department or internal IT meeting regarding BSS
upgrades.
2) Find constraints
Find systems in your architecture which throughput could lead to increasing throughput of entire BSS.
Think about where you invest most of your time and money. Search for parallel systems or
functionalities (e.g. 2 provisioning systems), obsolete processes, unsupported processes because poor
level of integration, mystic systems which functionalities you don’t fully understand in a BSS scale.
It is smart to use some type of metric system (semaphore, MOSCOW) to prioritize and define type of
changes needed to improve your BSS. Example with semaphore: red are the modules which should be
replaced with new or similar existing system or refactored, yellow are the legacy ones which you will
not consider sorting out immediately, greed are the new ones with good architecture. Contact all
responsible parties with your findings (vendors, partners, internal IT/developers), hear them out
what they can do for you and how much it would take.
3) Improve your pipeline
Think about your current pipeline. Which change requests are usually required by your business in
your delivery pipeline, how often, what systems are impacted by the change requests and how long does
it take to deliver these changes to a live environment? Could this be improved? Internal continuous
integration (deployment, delivery) project or automated testing could speed up your delivery pipeline.
Using the same pipeline processes and tools (PM, versioning) by all parties involved in delivery pipeline
(business stakeholder, product managers, delivery, support and vendors) will bring clear picture of your
current pipeline throughput, pending and future tasks and is a cornerstone of DevOps. From there you can
measure and optimize.
4) Look ahead
BSS transformation should support business transformation. Think about convergent offer (services)
your company would like to implement in the future. It is good to have planned your transformation around
existing services and offer but prepare also for type of service your company would like to offer in the
future e.g. convergent offering. It is good to check what others with business verticals like yours offer.
Discuss future offer and business transformation (direction) with your stakeholders as well. How can we
make our BSS more flexible for supporting these types of services? What would it take to support and
implement these services in BSS?
5) Think cloud and think platform
Where possible, move your services to the cloud (private or public), the age of on-premise solution is
coming to the end. Big transformation potential lies in public cloud services like Azure, AWS, etc. Also,
think about cloud platforms that could take the heavy load of your BSS with OOTB services and solutions
like Salesforce, Oracle, Microsoft provides. These platforms could decrease BSS complexity immensely.
IaaS and PaaS solutions also lead to drastic time and effort reduction of your BSS operations, support,
and maintenance.
6) Rethink your internal business processes
Sometimes poor implementation choices are made from poor processes. Sometimes this means missing
responsibilities in the company (business analyst, PMs). One of the examples of poor delivery processes
is too much Waterfall project structures. Think about what the Agile process would bring to the table
and what it would look like in your company. Recommendation is to use industry defined processes like
TMForum Frameworx so you could use defined models that support your business as well.
7) Iterative transformational improvements
BSS upgrades towards transformational goals should become part of your standard pipeline and upgrade tasks
should stand next to your regular business projects or change requests. Smart move would be to check if your
ongoing changes on BSS moves you forward on your transformation path or no. If you struggle with handling
current amount of regular business projects and change requests, maybe constraint is your pipeline or your
delivery process? Agile process introduction and pipeline improvement discussed in previous points will help
you here.
8) Discuss goals with stakeholders
This is the most important point. If you are a CTO, explain BSS transformation goal to board members. If
you are a transformation project owner, explain it to delivery managers and stakeholders, explain it to your
vendors. Show them the figures, explain constraints, talk about current architecture and how you can support
ongoing and future business offers and services better, save costs for the company and increase time to market
by increasing pipeline throughput. And finally, listen to all of them, those are the people who will set and
approve your transformation goals and whose inputs will impact the project plan, priorities and tempo directly.
Once all those points are set up, you can replace parts of your legacy landscape, choose new systems that fit your needs better or transform legacy into a more modern solution. After a periodical check-up, you will see how much you achieved and where to put an extra effort if needed. Hope this was helpful and good luck on your transformation path!
