Maybe it was driven by something as simple as the fact that International Rescue and MEGA International are united by the word ‘international’, but my mind wandered to imagining what it may look like if MEGA formed its own version of Thunderbirds’ International Rescue – but this time in the form of a secret but not too secret worldwide organisation that is dedicated to saving businesses significant costs and rescue consulting projects. We’re not saying that we’re puppets, but you follow the drift!
It’s not such a fanciful idea in reality, and in many ways MEGA is actually setup in a similar way with similar goals.
MEGA are already aided in our mission by technologically-advanced land, sea, air and space consultants that are called into service when conventional rescue techniques have proven to be inadequate. We swapped a Pacific Ocean base for the beautiful city of Paris. On top of this we have a world-class technology that provides the platform for the consultants to architect the best solutions whether it’s a response to an emergency situation or a more strategic transitional scenario.
The MEGA ‘Thunderbirds’ team and fleet looks a little like this:
Thunderbird 1: A hypersonic business architecture used for fast responses and disaster zone reconnaissance missions.
Thunderbird 2: A supersonic carrier craft that transports project managers and consultants directly into disaster zones using the advanced detachable pod capsules that closely resemble the components of HOPEX.
Thunderbird 3: A single-stage-to-orbit capability approach. And we also have a pilot named Alan.
Thunderbird 4: An industry-leading EA utility submersible that is normally deployed from Thunderbird 2.
Thunderbird 5: A space station that relays distress calls from around the world – as well as our Paris basecamp we also have several satellites around the globe for even more efficient servicing.
You can contact MEGA’s Tracy Island via this link, and we’d be happy to discuss rescue and transformation options for your organisation.
... View more
We aren’t the traditional ‘3 years and change’ purchasers, choosing instead to buy and keep a car for some years. We’ll often make minor changes to wheels, brakes and other stuff to ‘make it our own’. Maybe it’s because of this that we fell foul to an interesting situation with our most recent purchase? This got me thinking about the broader concept of the customer journey, and how what cars my family and I choose applies to it.
We already knew the car and model we liked, it was just time to upgrade to a newer, higher spec, lower mileage model. In the months leading to the decision to replace the current car, a service was due. During the service a worn engine part was noticed and I telephoned to order it at my local garage’s request. Several phone calls later and I eventually managed to convince the manufacturer that this was indeed the part I needed and that they didn’t need to check it for me. Better still, the local garage would allow me to keep the loan car for the two days.
Despite chasing, it took nearly a week to receive the part and then the service team refused to deliver it themselves to the local garage despite it being within sight of their premises! My local garage went and got the part themselves to speed the process up as at this point I had been without a loan car for close to a week.
Fast forward a few weeks and all is well. We’ve decided on the exact model we want to upgrade to and a quick tour of the web reveals there is a fine example in the dealership ready and waiting.
Around this time, I took our other car to the local dealership to book a service … still well under warranty so no decision there! I was surprised to find the same model that we were interested in sitting in the carpark outside the dealership with a for sale notice. Further investigation revealed it was a trade in. The price and mileage were comparable to the other manufacturer’s dealership and a decision had to be made.
So do we buy one make of car instead of another just to get that level of better customer service – yes we did!
Why are things so different between the dealers then? I reflected on this for some time before I came to the most obvious conclusion… that one manufacturer view the after sales team as being equally if not more important than the pre sales team. They recognise that this will have a greater effect on resale than anything else – so much so that the most senior member of the dealership in our local dealer is the head of after sales.
Knowing not just your customer, but what influences and motivates them is a huge business tool, and is essential in an ever-competitive market. Being able to track where the touch points are and continual assessment of weaknesses and strengths can allow the business to focus and succeed. It’s all about the customer journey.
Download our eBook to gain insight into mapping your organisation’s customer journey, rate customer satisfaction on touchpoints, design new processes and reinvent existing ones, and evaluate the effectiveness of your processes.
... View more
When you migrate one system to another there’s a simple and logical rule…the system that you’re moving to has to be at least as capable and as ‘big’ as the system you’re leaving behind. You can’t move to a smaller house and sensibly expect to contain the same volume of furniture without clutter and overcrowding … or ‘issues’. Don’t get me wrong, people can and do downsize, but it’s often a traumatic process!
Modelling tools are no different to any other system or for that matter house move… you have to have the right ‘container’ for the information…
Here is a checklist of 10 questions to consider before switching your EA solution.
What type of models have been built?
How many of these models are there?
What notations have been followed?
What methodologies and frameworks have been adhered to?
How up to date and valid is the content?
Has the tool been configured/customised/extended?
Who uses the models?
Who maintains them?
What experience or training do they have/need?
Who are the model owners?
Once you’ve answered these questions, here are some further elements to considering when looking at a new tool that you will be migrating to. Firstly, is it new tool seamlessly able to import the old information in a non-manual way to cause minimum disruption?
Transitioning to a new tool (just like moving into a new house) is no easy task. Once you’ve chosen your new house, you’ll need to think of how you’ll move all your possessions and plan where these will go for that seamless move. This is the same with your EA software and all the migration of all the information. How seamless will it be to import your information into the new tool that you’ve chosen?
Some tools allow you to examine the content of the source tool model(s) and provide an efficient and visual report of the nature of the content of the model – its structure, volume of information held within and identify any configuration/extensions? With this model ‘blueprint’ you will be able to determine what you’d like to migrate - or if you prefer…do you intend to move all the furniture to its new house or take the chance to ‘lose’ some and get new?
Secondly, once you have this your migration list, how easy and accurate is it to map and import this into the new tool so you know what furniture goes in which room? Analysing, understanding and signing this off upfront before the move, will ensure a smooth transition of all your data.
Finally, how experienced is the new tool provider that you will be switching to? When moving homes, a professional removals company will take the load of your mind as they have the experience in packing and getting you moved into your new place. In the same way, it is essential that you can leverage from the experience of your new tool provider and gain their support to make the whole migration as flawless as possible.
Once this done, you’ll need to ensure that those involved are trained to use the tool. This is where the more intuitive the solution, the faster they’ll adopt and embrace the new workspace…(move complete. It’s time to settle in!)
Migrating to a new system is a big step, however, with careful planning and the right tool many of the associated risks can be alleviated, paving the way for a seamless transition. For example, being able to map and visualise where your content will go up front will relieve any issues when it comes to content migration, while leveraging from your chosen tool providers’ experience and expertise means that they can guide you in the right direction to ensure the success of your transition to your new tool.
... View more
Sounds simple right? In principle it is, but many organisations struggle or mitigate the risk of failure by asking a Business Change partner to assist.
These partners send in troops on the ground to provide expertise, specialist skills and above all a method to deliver the TOM. Many of the 'big six' provide exactly this support and equally a number of smaller industry specialists are available to help.
With all but the simplest of TOMs, a vast volume of information about the organisation is collected, catalogued and assimilated into the overall 'model'. This 'model' will normally be focussed around the main Processes or Capabilities of the organisation in the future, with other domains like Applications, People and Technology, being related back via matrices or looks ups. Then, with the target mapped the gap between the TOM and the current organisation can be determined before the interim stages described and planned.
Clearly with a lot of information being collected around multiple domains and typically with several layers of detail, managing the content quickly becomes time consuming and subject to human error. Remember we can also add time and stage deliveries into the mix and all of a sudden MS Office based tools start to creak at the seams.
A repository based modelling tool can massively reduce the human effort, provide standards and automated controls of the volume and content. The ability to create stage models to aid transformation and of course integrating different types of modelling information into a single central place is enormously powerful… then if we add in value added reporting, gap analysis and automated views… well all of this is clearly common sense to have if you can?
I'm pleased to say most organisations and change partners recognise this ...but normally AFTER the TOM Programme has commenced... This means semi or non-structured data is already collected and needs to be 'massaged' into the modelling tool. Advanced tools carry standard repository standards for TOMs, but clearly if these aren't used from the beginning it causes rework and can be time consuming. This in turn slows progress and often highlights gaps, inconsistencies and, in many cases, the need to go back and re-run workshops and interviews...not good.
If however the modelling tool can be engaged early in the TOM, the on-board standards, best practice and methods can be engaged - leading to more efficient workshops, interviews whilst providing instant model outputs with the facility to deliver signed off processes in the live environment ... The secondary benefits around content management, analysis and of course progress tracking can then all be taken advantage of.
So is it possible to start a TOM and bring in a modelling tool later in the process? Yes, but it costs more, is harder to socialise and above all often can be politically hard to explain as to why it wasn't deployed from the beginning...
... View more
Where does model sickness strike?
The condition can normally be found where a ‘flat file’ style model is being used – i.e. diagrams without an underpinning database or clever way of storing other dimensions of information. However this sad condition can occur even when database based systems are in action.
How do I recognise model sickness?
A diagram that needs such a complex key of symbols used that you have to read it more than once and still find yourself confused
A diagram that only one ‘special’ person knows how to maintain and explain
A series of shapes where the shape itself is made up of many dimensions such that you have to have a sub key for each type of shape
A reluctance of the modeller to make changes as it’s so time consuming
Users that avoid trying to use the model sick at all costs
How to avoid and treat model sickness…
To avoid model sickness here are three points that are worth bearing in mind:
1. Who is the end audience which the diagram/model is aimed at? If it’s for more than one audience then are you quite sure that a single type of diagram is the best vehicle? A plumber uses a very different diagram to an electrician – it’s the same house, but different notation… 2. If you’re finding that a larger and larger page is required then are you sure that you’re capturing the right level of information and in a digestible format? London underground deliberately ignore distance in their tube map to allow all of the main stations to be seen in a single concise page… 3. Does the diagram/model continually seem to be out of date? Are you quite sure the model is still of use and/or value for the end users? A model which isn’t maintained for a reason or has slipped out of date is sometimes worse than no model at all… How many times has a road changed compared to our satnavs and led us to stress and frustration?
Model sickness can be a serious condition but the good news is it is easy to avoid by simply remembering that a model by definition is aimed to show a simplified representation of the real world and not rebuilding the world’s information in a different way! As much as models are essential, ultimately what matters is the endgame – that is meeting the needs of the business and their expected business outcomes.
... View more
In my tinkering I’ve come across a few special bits of kit that aid in the various tasks I’ve set myself – some are entirely mechanical and some less so. These days modern cars have a ‘brain’ – an ecu that manages any of the engines sensors and feedback systems, telling the car when to use more or less fuel, apply anti-lock brakes etc. When dealing with any aspect of the ecu you are entering the ‘world of the dealer’… a strange land in which a dealer will plug in a cable to your car and let it tell the computer what is wrong, what needs doing and when…
I don’t like dealers as they tend to be less ‘gentle’ or let’s say appreciative with the hard work I’ve usually put into one of my cars… Imagine how happy I was when a friend pointed out that I could buy my own diagnostic kit to plug into the car! I could even (when brave enough) look at tuning some basic aspects of the car!
So I happily installed the little box with the appropriate cable and immediately got worried as the loading screen appeared … this wasn’t my weekend toy I was about to play with… it was my daily driver. Backing out of the situation I decided this was a ‘Sunday’ job and as such put the new toy at the back of the garage vowing to read the manual ‘soon’.
I never did read the manual and after a long embarrassed silence with the same friend, admitted I had half hidden the box to avoid the inherent ‘guilt’ of seeing it in my garage.
Reading forums of other owners and sharing my pain I found out pretty quickly that I wasn’t alone … and that there was light at the end of the tunnel… a proper tuning house! They would take my new shiny box of tricks, install it and set the car up for me… yes for a charge, but they would take on the risk of the work. What made me more interested still when I called to speak to the tuner was they wanted me to come with them on the test drives and have input to the tuning sessions – saying yes or no as the custom tune was configured!
The result is a car I’m happy with, it uses less fuel, goes faster and I know has a safely installed tuning box… Essentially I’m getting the most for my investment.
This made me think of my field in which I work in, where I oversee many organisations through large-scale business transformation. Buying the software solution is a solid first step but this alone may not be enough to unleash the true potential of what can be achieved.
Ultimately, when you buy a specialist tool or software solution, you need to consider the risks of what you’re about to embark on. You need to decide if you’re happy to take all of that on your shoulders and ‘make it work’. If like me the investment is a little greater than you’re prepared to just risk on your own, then perhaps engaging a specialist organisation who have experience, can make recommendations as to what works and above all will involve you in the end product … well wouldn’t that make more sense?
... View more
Hi There, MEGA are in the final stages of negeotiation with an organisation called BDNA (BDNA.com) to provide pre-populated lifecycle information within MEGA. The BDNA 'Technopedia' tool will be used to achieve this. Lorne
... View more
Folks, These are interesting questions and highlight that whilst Libraries are hugely powerful and useful, they do require some thought as to how they're going to be used in practice at the time of implementation and, really, to be able to give concrete advice requires more than a forum post... Firstly, a bit of a generic note about Libraries:- I've dealt with Libraries in a couple UK clients as well as using them in my own content and the most important thig to realise is that they are simply a method of segmentation and grouping content within the tool. Because of this the actual groupings used from client to client differe depending on how they see the world. Sometimes the company takes a "Zachmann-style" view of the world with segmentation between Contextual, Conceptual, Logical and Physical (as well as such classifications as "Transformation" ) and sometimes the line is drawn between disciplines so "Infrastructure", "Application Portfolio", "Process", etc. . Neither of these are right or wrong. What should be said though is that in neither case was the stable structure created on the first go - there were a couple of iterations where the initial structure was too simple and then it became too complex to be easily used and, well, now they work. So in summary, there is no right answer to libraries and there will always be some trial and error because the first thing you need to do is work out what questions you're trying to answer in your organisation and once you know the questions you can re-group to structure your world in a way that it does answer your questions. Phew... So, lesson over ( ) we can move on to the joys of migrating objects between libraries (jtinoco's original post). For this, let's imagine we have 3 libraries which we'll call "As-Was", "As-Is" and "To-Be". "As-Is" and "To-Be" are pretty self-explanatory, but "As-Was" is where retired objects and descriptions (diagrams) go. We also have a Library called "Transformation", which is where we keep our Project portfolio modelled using the "Project" object. This is the key to the whole solution. When deciding the scope/calculating the impact of your new project you connect the objects and descriptions to be replaced which, of course, are in the "As Is" Library to the Project Object and define them as Changed/Replaced/etc.. As you create the new content that's going to replace the current project scope then you connect them to the Project object saying they'll be introduced (you're free to choose your own words for these terms btw.). This all means that on Roll-Out Day you'll have two sets of objects in your Repository - The first is a bunch of objects in your "As-Is" Library connected to your Project. The second is a bunch of objects in your "To-Be" Library also connected to your Project. The first set of objects can (after the appropriate checks to ensure the content is correct) be moved to your "As-Was" Library and retired (but is still somewhere it can be re-introduced easily if needed - always have a back-out plan!) whilst the objects connected in the "To-Be" Library can be moved to the "As-Is" Library. Because you have that core connection that makes the scoping of what you need to move easily queryable this is much easier than before. You may find that rather than connecting every single object impacted by a project to the Project object you may be better linking the high-level Applications, Systems, Organisational Processes and Org-Units and using the concept of Boundaries, which is something that falls into the category of "Product Engineer Black Magic" and is outside my knowledge-scope. Simon adds an extra dimension of fun to all of this by asking about sequenced projects changing the same object. The approach I've outlined above helps with this as one should question if an object is marked as being impacted by more than one porject then maybe those project teams should be talking to each other (I know, I'm an idealist...) and you will know that the project witht he later release will be changing not the object as it currently is, but how it will be after the last release. In this case I would say that there's probably a case for a "Big, Distant Delivery"-type Library. This should CERTAINLY NOT be in a different repository because then you'll lose all the value of impact-analysis. That's been a monster, but I hope it helps, Alan edits to sort typos and grammatical errors
... View more