What's next after Cloud ?

By S.Suren

Well, everyone is talking about cloud computing, have been talking about it and most likely will continue doing so for quite some time into the future too, so then what's next after cloud ? My guess, is after cloud it's just going to be more of the cloud and new ways of dealing with the cloud.

Cloud computing has taken the world by storm, the dependence on the internet these days for ERP vendors is more so than ever and that will only increase. As far as the terms go, the term cloud computing will die out soon, like it already is and new terms to define new ways of working with the cloud will evolve.

Apps talking to each other in the cloud, complete ERP systems and its integrated parties will all be hosted in the cloud. More transactions will be carried out in the cloud than single servers and with the increase the technology infrastructure its only about time until complete databases and predictive analysis data is held in the cloud and respond directly based on inputs received from connected systems.

I wouldn't be surprised if in 50 years time, places like schools and work offices will be considered a thing of the past, everything will be hosted in the cloud and can be done in the cloud itself, drastically reducing the need to commute. Just take the various e-learning solutions and infrastructure that is being built in the cloud and that itself is a great indication to suggest that students will no longer be sitting at desks in front of a teacher in a class , but rather in front of a computer monitor at home attending classes, submitting assignments and ordering their favorite type of plaque for their certificates as well, not that it is not being done now in some countries, but all this will probably be done throughout their entire schooling life in the future.

For more for on cloud computing you could visit similar articles on :

• http://www.infoworld.com/
• http://www.pcmag.com/

Hope you found this post informative, feel free to drop in your comments on ssurenlk@msn.com

Movements in SAP HQ

Given that I'm involved in SAP, I thought I'll share with you all some changes that have taken place at the  SAP HQ very recently.

If you haven't already read about it, the head of product development Vishal Sikka very recently moved out in a move that is being deemed as "all too sudden". He was the champion of Hana, the in-memory computing platform that SAP is working on with head over heels right now.

Shawn Price, SAP's cloud software sales chief has moved away as well, though it was a short gig since he, this is another high profile movement within SAP HQ.

The final one is something that is likely to come by soon, where the Co-CEO Jim Hagemann Snabe will be stepping down leaving Bill McDermott as the sole CEO of SAP.

People move in and out of organization that is nothing new, but it doesn't hurt to know what's going on in terms of the executive players moving around in the ERP world.

The Changing ERP World

Gone are the days where you would look at an ERP for just the purpose of controlling your cost,  providing you an integrated view of all your Business Processes and other sub-processes that help you make smart effective strategic business decisions.

Today’s ERP requirements spans well beyond the ones mentioned above, which is why most ERP vendors need to strike a balance between 2 variables that always pull in different directions, i.e. Complexity and Flexibility. Today CEOs, CFOs, COO's are talking about sustainable IT solutions not necessarily only CIO's. The onus is on technology based solutions that can initiate organic grow from within the business pushing for  the inside -out towards changes to business processes.

The changing trends of ERPs & IT systems is to be able to be record and analyse external factors of a business process and provide insight to the organisation. Focusing on just manufacturing, logistic costs and others will surely help the company a lot in terms of improving their  bottom line, but today’s management trend is to be able to perform these tasks by  taking into consideration likely changes in the external environment on their internal operations.

If you work in this ever changing ERP environment, it has become absolutely critical that you upgrade your technology  "savviness" in areas which will help you to have something to offer when it comes to the technologies the clients are now more interested in. Best advice here would be to read websites in your areas of expertise.

Here is a list of sites I would recommend:

• http://www.gartner.com
• http://www.technologyevaluation.com/
• http://www.computerworld.com/
• http://www.informationweek.com/

People talking about the future of IT these days are not in IT at all, but rather people who are affected by changing technologies and who have begun adopting the new technology not via a business software but via a personal one. So being in the IT industry , your success would be more about understanding and be understood by  the "new people", after all there is no business if you don't understand your customers , right !!

Have a nice day.

Watch out for "Point & Click" Solutions

By S.Suren

More often than not in any system implementation you would come across a solution which caters to just the one particular business challenge, this is what is termed as the "PCS - Point & Click Solution". As the name suggests this tends to be a solution that is provided for only what is seen and not for what is not in focus but still constitutes vital working elements in the overall environment.

It is also very likely that there have been other significant changes that have come about in other process areas due to this particular solution that has been implemented. Doing a proper "Requirement Profiling" will help eliminate a situation like this occurring.

The key steps of Requirement profiling :

• Identify the business system landscape and where exactly in this landscape does the business challenge reside.
• Identify information tunnels flowing inwards and outwards from this business area.
• Ascertain if the solution needs to be deployed in any  preceding or succeeding activity as well. This can done by drawing up a process map.
• Identify the impacted users of this business, which departments they relate to etc.
• Identify the business drivers behind the requirement. Who and what changes in the business has brought about this requirement.
• Identify the business risks of deploying the solution in the current business areas and also other integrated business functions.
• Most importantly also try and identify other solutions that are being put in other areas of the business which could potentially be integrated later on.

Performing the above profiling activities will help to understand the overall environment where this business requirement & challenges reside and also help with identifying the best approach in deploying a solution.

There are many other similar approaches to profiling a requirement and these would be carried as part of requirement gathering / blueprinting , however this doesn't always happen and therefore performing a thorough requirement profiling activity as part of requirement gathering would certainly help.

Hope you found this post informative. There is so much more that can be added on this topic which I shall do later on in my future posts.

Have a nice day.

Wishing all my readers a "Safe, successful and fun filled New Year !!"

All the best in 2014 !!

"Time is always on our side, it just depends on what you decide to do with it"

Thank you for all your interest, support and comments over the year.

New System, less work.. No not really !!

The most common misconception of a new ERP  system implementation is that it reduces the amount of manual work involved and is going to mean less work for the users. This is not entirely true, though a system's role would be to make life easier for the user, over the years the primary role of a system is to help organize business processes, eliminate non-value adding activity, capture the information/data flowing through the business,  analyse and project this date to the management to provide better insight into identifying trends, highlight  business challenges and areas where management need to give special attention to.

In essence, once the system is up and running, the above would actually push the management and users to move onto the next level to make sure that the analytics performed are done on a sound basis to ensure the information used in decision making models is relevant.

A successful implementation of a new system will always bring to light new areas, processes and business challenges which the users didn't know before existed, this then gives them the opportunity to focus on improving these areas & processes in order to be to get the best out of them.

I've come across many users who have initially mentioned that their workload has gone down dramatically but in a couple of months time, they are running reports which have brought to light many areas in which the business can do better at and this leads to new work (opportunities) to get those areas improved as well. An ERP Implementation is a continuous improvement process,  there is always room for improvement which might highlight a critical piece of information that could take the business to the next level, and these improvement opportunities will not always be identified by an ERP system, most of the time it will be highlighted by a hard-working super computer, the "Human Brain".

So remember an ERP system is more than just making life easier it is about taking the business to the next level, if users expect an ERP system to do everything that they do, there wouldn't be a need for a user to come in to work at all.

Have a nice day.

Symptoms of an “Over engineered system”

Wikipedia: “Over engineering (or over-engineering) is the design of a product to be more robust or complicated than what is necessary for its application”


So there you go, the definition in Wikipedia for "Over engineering" is as simple as they come. As a consultant, having implemented many different ERP solutions across various project globally, I cannot say that I’ve not had firsthand experience working with an “Over-engineered system “and when I do, I think to myself who let this happen and why is it still in existence, but the reality is when a system that is more complicated than what is necessary for its application becomes a process in a chain of operations, it becomes the hardest process to replace!!

In this article, I’m going to list down the symptoms of an “Over-engineered System”, so if you see any of below symptoms in your organisation for a process...then “Voila” ...someone’s gone overboard with the design:

• Only 1 person clearly understands what the specific application area does.
• There is no one place to get all the documentations explaining this application area.
• No one wants to have anything to do with the application area.
• Other areas around the “application area” have changed overtime.
• All the other areas have been changed to suit the workings of this particular “application area”.
• Many external contractors have worked on different sections of the application area, all at various points in time.
•  The senior management hardly knows about this application area, though it feeds into the information system that is used solely by the senior management.
• This application area is not associated with routine tasks on a day to day basis in the business.
• Reports relating to this specific application area are done manually in “Excel sheets” rather than an integrated system report.

These are some of the clear symptoms of an “Over Engineered system”, if any application area satisfy most of the above bullet points, highlight it and make an effort to try and re-engineer it, and this time follow the KISS Principal – “Keep it simple, stupid” – as articulated by Kelly Johnson.

Hope you found this post informative and interesting.

Enjoy, have a nice day.

Human-centered Design (HCD) enabled ERP Solutions

The term human-centered design (HCD) seems to be used mainly across the development stage of a product which involves human interactions, in basic hindsight HCD is simply a designing approach keeping in mind how easily the end user, i.e. a human, would interact with it and for how long will he/she will be able to continue using it in its true form.

There are various technical jargon's associated with it that makes it sound far more complicated than it actually is.

Many companies struggle with problems caused by bad usability of their products although they have invested in human-centered design (HCD). Their product may still have not gone through a systematic approach, adequate knowledge and a clear definition of responsibilities in HCD.

In this article I thought I’ll share with you a few HCD principles that can incorporate into any ERP solution design.

Some of the HCD elements that could be used would be:

Usability – ability of the users to use the function with minimal supervision.

Maturity – ability of the user to understand the core function of the solution and being able to branch out into other related areas to understand the functionality in its entirety within the organization.

Participation – Assess the solution based on how much the user would be able to participate if a change is to be made to the core logic.

Piloting period – Assess how long is it likely to take a new user to take over the functionality from an existing user, the lower the better as it indicates user sustainability.

Most often than not, these are discussed in a project environment, but laying them down and assessing them during the development process will definitely help in delivering solution that is more human centered and more sustainable.

Hope you found this post informative. Feel free to contact me on ssurenlk@msn.com.

“Ways of work” in an ERP Project Environment !!

By Suren

 

Most often than not the ways of work listed below tends to take place in a general project context but more than often in a non-controlled manner, there are no straight forward guidelines to set this up or to be able to control this, but as a Project manager or PMO the environment to encourage this can be built. Below are some of the ways of work I have identified together with some recommendation to build the right project environment to encourage this behaviour or at least not discourage them!!

 

Invisible Work

 

Most of the time there is an amount of work undertaken in a project that is not recorded in any project document or process documents,  yet it adds to the overall process improvement / project implementation and most often than not this is a task the individual takes on not expecting any recognisition.  Underlying pre-requisite for this is to give members the ownership of the project, too many controls in the project environment and the positive effects of invisible work dies out and the negative effects spreads within i.e. lack of ownership, team disconnect, work to rule syndrome etc.

 

Impact groups

 

This occurs when individuals form a bond together on a particular problem within the project and then work together to solve it and then move away. This group tend to be very efficient than the groups that has been setup to solve an issue since Impact group’s main focus is to get the job done and move on to their routine, so by human nature they work to solving the problem sooner than later. PMO cannot identify these groups until they are formed, but when they do they need to make sure the individuals in them are allowed to move on to other areas once the issue is rectified, if not this group’s efficiency tends to fall if there are not moved around.

 

Influence teams

 

An influence team is created by combinations of business users who come in from different areas of the business and some external parties either directly or indirectly connected to the project. From a project point of view, the PMO needs to be able to identify these influence teams and make sure that either they or their ideas are brought in during project requirement gathering phases, more often than not the business users are the only ones involved, but it wouldn’t hurt to bring in the external parties as well, I’ve seen this happening in only a few projects.

 

Hope you found this quick post informative, I’ll be adding more of this as it hovers above me......

 

Have a nice day!!

A “Fail–Fast” approach in Project Management

By Suren

I’m sure you've heard of Fail fast systems and fail fast modules, where the system or module is designed to immediately report at its interface any failure or condition that is likely to lead to failure. Fail meaning to stop operation once there is a detected possibility of erroneous behavior and Fast means to report the failure as soon as possible.

Generally, in projects where there are delays the Project Manager steps in to identify bottlenecks and activities along the critical path, then undertakes activities that can be carried out faster either by putting in more resources or tweaking the outputs required in order to bring the project tasks back in line with the timeline. This kind of approach is in essence a variation of the fail-fast methodology.

Some of the Project management tasks that could be undertaken to build up a  “fail fast” model in the context of a project environment could be to:

1.Have regular meetings on Project tasks but with an emphasis on time of completion as per the critical path, rather than simply of menial tasks.

2.Nominate, one single responsible person to keep track of tasks and deliverables that fall into the critical path, someone other than the project manager.

3.Have regular submissions from project team on plans for forthcoming deliverables, especially those within the critical path.

4.Empower project members to take on tasks relating to future deliverables which fall along the critical path.

5.Clear out "noise" resulting from previous tasks delays that are not within the critical path, doing this will allow time for resources to focus more on project deliverables tasks that are more important.

6.Clear identification of risks associated with each deliverables and appropriate assignment responsibilities to project individuals to manage these.

7.Build up a flat structure for project teams in order to encourage issues being highlighted to the top. In a tall structure, the bottom-up information flow  takes longer which hampers the efficiency of an immediately reporting mechanism which is key to an effective “fail-fast” system.

8.Set up several checkpoints within tasks. Reporting could be encouraged at each checkpoint rather than tasks completion or progress.

9.Promote decision making at lower level meetings rather than escalating all decision making to higher ups.  Responsibilities need to be well documented for those decisions taken on critical path tasks.

10.Create an effective culture within the project team, to encourage individuals to be able to identify those critical path tasks that precede their actual task, in order  to be able plan for contingencies in their area in case of any delays.

A proper project methodology will tend to address the above, however following a structured approach in embedding these into project tasks will certainly help enhance the benefits of  a ”Fail-fast” approach. This would in turn prove very useful in avoiding delays in critical paths and budget overruns.

Hope you found this post insightful. Your comments, suggestions are welcome on ssurenlk@msn.com.