How relevant are Gartner and other tech analysts really?

How relevant are Gartner and other tech analysts really?

I was at an event recently organized by Sage software in Johannesburg. This was an event to promote Sage’s independent software partners to other consultants and customers in it’s large community. I spent a lot of time talking with various people, many of whom operate fairly small businesses but are very knowledgeable of their area of business. It was only afterwards that I realized I was never asked how analysts rate our platform, rather we were asked what we did and how we might help. In other words, none of the attendees cared, or even knew, about Gartner. Continue reading

Advertisements

Helping SMBs move to the cloud

cloud-computing-626252_640The increasing adoption of cloud computing by businesses doesn’t appear to have convinced many small and medium businesses (SMBs) in the UK to move their business application from on-premise to the cloud. The three common concerns mentioned are:

  • security of the cloud, particularly data privacy,
  • complexity of migration, the amount of time is takes to migrate, and the downtime while migrating,
  • cost of migration, with many believing that the costs are high.

Although I haven’t found the evidence, I suspect the same reluctance holds true for SMBs in other countries. The question is – are these concerns valid, and how can SMBs mitigate their concerns and the risks. Continue reading

Bimodal IT doesn’t mean complexity

bimodal_itFor over a year the Gartner analyst group has been talking about the need for ‘bimodal IT’. An article in InformationWeek described it as the need for an IT organization to

split its focus between the core services that make other things possible and the more exciting possibilities of digital innovation.

When I first heard of bimodal IT I was still working in the ERP software space. Coming from that traditional background I used to think that any bimodal IT effort had to be somewhat big and complex. But now I’m at a cloud software company I’m beginning to see things differently. Continue reading

Why the US is different to other countries

I have just spent 10 days in the USA, split between a week just south of Los Angeles in Costa Mesa, and several days in Lawrence, Kansas. Although I have been to the US several times before, this time it was different, for reasons I explain below. But also because I may have figured out the essence of what makes the US different to other countries when it comes to business and technology.

My previous visits were either as a pure tourist, or as an overseas employee of a US company coming to get an update on future plans and directions. For those work-related visits, I was a passive recipient. This time it was different. I went to the US to attend a sales conference organized by my employer in South Africa. This time I was one of the people helping to set future plans and directions. This time I had to actively engage – mainly, though not exclusively, with people who work in our North American offices about their concerns and issues.

One of the ongoing issues is that we, i.e. South Africans, don’t understand the US. In the past, I have always supported the view that while the US may start earlier with certain things, there’s not that much difference when it comes to business. But at the end of the sales conference, I had a strong feeling that things were much more different than I had been able to understand.

On my previous working visits, I received direction from US head office people, and used to consider them rather ignorant of the world outside the USA. Now the roles were somewhat reversed: I was the head office person, and they were saying people like me were ignorant of their world.

It took a few days after the intensity of the sales conference, staying with family in Lawrence, and talkininside Dillonsg with my South African brother-in-law who works at the University of Kansas, to distill what I think is the essence of the difference. It was after a visit to a local supermarket, Dillons, that it occurred to me.

It’s what is considered basic.

For each product category, e.g. bread, the range at Dillons was two or three times more than I have seen in South African, or UK, supermarkets. Moreover, the products in Dillons exploited every single consumer niche you could imagine, no matter how specialized the niche. In others words, the choice and competition was greater than I had experienced. I surmise that this makes US consumers more demanding than consumers elsewhere, and makes what they would consider basic different.

When hearing the North American sales people talk about their market and competition, the same kind of impression arose:
product category range + exploitation of niches = high degree of expectation from business

Perhaps it’s because the US economy is so highly competitive that the basics are different – in supermarkets, in business, in IT (and if you watch any reality TV, in relationships).basic differences

It’s something for both sides to consider. If you enter the US market to do business, be aware of how the needs and requirements will differ and be at a higher level. On the other hand, for US companies operating internationally, don’t expect the same issues to be of concern, and don’t assume US concepts are universal.

When it comes to business software, the requirements of a US business are likely to be greater or more detailed than business in other countries because what is considered basic fo US business is different. The same duopoly then applies – overseas software companies must get really immersed in the US to learn what is needed, US software companies may not find the same functional requirements from businesses in other countries.

Twenty questions for CFOs embarking on an ERP project

cfo-questionsAs the CFO of an organization, your responsibility is to ensure efficient and effective financial operations and records, and influence overall strategy. An ERP is the foundation of the operations of a business. For a CFO, it enables you to track and report on all business transactions, analyse information, ensure governance and compliance, and increasingly do this via mobile devices. Therefore, you need to be very sure your ERP project will deliver what the business requires, and also what was promised.

Before going ahead with an ERP project, you should have addressed these questions.

Planning and selection

  1. What is the executive board’s experience with business software? Will there be sufficient executive involvement beforehand, and how will it be maintained during the project and afterwards?
  2. Are the business objectives clear, and is there detailed understanding of what you want to achieve? Do you just want a new system, or do you want to change the business – its processes, what roles people perform?
  3. How will you engage with vendors? Will you short-list with the use of an extensive RFP (Request for Proposal) sent to lots of vendors; use recommendations and peer contacts to identify a smaller number of vendors; do your own research on the Internet to identify possible vendors; employ the services of an external consultant?
  4. How will the chosen solution impact the way you do business – what aspects will it dictate to you, and what can you change to suit your needs?
  5. What benefits do you expect, and where will you look to find:
    1. Increased revenue
    2. Decreased costs
    3. Improved quality
    4. Better customer service
    5. Shortened manufacturing cycle time
    6. More accurate inventory information
    7. More streamlined processes
  6. Have you got details of all the costs involved?
    1. For the obvious items – software, infrastructure, services, training, support
    2. For less obvious ones – budget for data conversion/take on, third party software integration, change management, process modelling.
  7. How will you ensure that the consultants engaged for implementation can be treated as:
    1. trusted advisors
    2. knowledgeable and experienced in your industry issues
  8. What are the cost, time and effort implications of upgrading the ERP software?

 Implementation and training

  1. Is the project scope clearly defined? How will you handle the scope changes that so often happen during an ERP project?
  2.  Are the right internal people involved? What might their agendas be?
  3. How will training take place? If the staff needs proper training, how will it be scheduled to minimize the effect on their day-to-day work, bearing in mind they will also need the time and opportunities to practice and learn the new skills.
  4. How will the project impact both the intended users and the current IT team? How will they manage time on work vs. on the project?
  5. How will the ERP software work with other applications that the business relies on?
  6. How easy is it to access information via reports, or other sources?
  7. What procedures need to be implemented to safeguard governance, regulatory reporting and compliance?

Ongoing use, management and maintenance

  1. What ongoing training and education programs need to be instituted so that staff continue to use the system effectively?
  2.  What strategies are required so that the ERP system encourages the standardization and classification of information across the business
  3. How will you extend the ERP system from just a transactional system to one that assists with planning, analysis and insight?
  4. What people and policies will you put in place to maintain the Return on Investment of the ERP system?
  5. How often will you review the alignment of the ERP with the business?

This was originally published on the SYSPRO Smarter ERP blog

 

Four tips for starting an ERP project

Cross-posted from SYSPRO SmarterERP blog

There has been a post on the SYSPRO blog on how an ERP system can help a business, and also some suggestions on how to select an ERP solution. But if you have read some of the stories about ERP project problems you might wonder if it is worth the risk. The answer to this is twofold.

  1. The reports on ERP project failure mainly refer to large organizations implementing fairly large projects, and are not representative of projects undertaken by small- and mid-size businesses.
  2. It’s how you approach the implementation that is a significant determinant of success or failure.

So where and how do you start?

The lead up to an ERP project is a good time to consider Eli Goldratt’s Theory of Constraints Thinking Processes, which is a set of tools to help organizations identify what can be done to significantly improve any business system. By the time you start the project you should have dealt with the question “Why change?” Now you need to look at the other questions:

  • What to change?
  • What to change into?
  • How to cause the change?

A number of organizations might think that all they need to change is their business system, when in reality they will probably also change and streamline processes, and realign roles and responsibilities. Therefore I recommend the following steps.

1. Do a business process blueprint.

To answer those “what” questions you need to understand the processes that operate in the business. A process blueprint provides a graphical view of the way processes work, who is responsible for the processes, and the interaction between different roles.  It also helps by creating a view of the business that both IT and business can understand and discuss – a common, visually-based language. From the blueprint you can see more clearly what might need to change (e.g., in terms of streamlining processes), and with a decent blueprint tool you can try out different changes to see what might be most appropriate. The blueprint enables you to identify solution gaps and define integration points between IT solutions.

2. Check that the key project issues are covered

Evidence from many projects shows that there are four main factors that create project problems, and so mitigating them will improve the chances of project success.

Main causes of project problems How to mitigate them
Unclear objectives and poor focus Focus on strategy, involve stakeholders and define project teams responsibilities and accountability
Changes in project scope Ensure project team and all affected staff are aligned to work towards common project goals
Lack of appropriate skills Ensure appropriate skills are available
Unrealistic schedules and poor planning Have a good project manager

3. Plan the project in phases

The implementation project plan describes how the transition from current state to envisaged future state will occur – it addresses “how to cause the change?” Plan the project in phases and implement over time, for several reasons.

  • It’s easier to estimate and manage the budget for a smaller set of tasks than it would be for a ‘big bang’ type of approach
  • It restricts the impact of the change to a smaller number of people, which means disruptions to everyday work can be minimized
  • Showing rolled-out wins will keep people motivated

4. Make sure change management is included
Forrester-change management
The biggest cause of failure in IT projects is not software, it’s ‘wet-ware’ (people). Resistance to change can block even the most perfect plans, so building active consensus and buy-in is crucial. Forrester Research offers the following steps.

Lastly, although you may have undertaken a thorough business process analysis, and done the proper project planning, be prepared for unexpected complications that occur during roll-out. This is especially true for manufacturing businesses with complex processes, and where integration with other manufacturing applications is needed. If, however, you have done the upfront work, you will be in a position to handle these complexities without seriously impacting the project or the business.

What is your experience with starting an ERP project? Have you got any other tips to add?

Responsiveness of cloud-based software

Clouds
For a while I have been using a web-based service called Mammoth. Mammoth allows you to save text, images and other online content, as well as notes, into a single place for later use. In my case, I use it when researching issues I need to write about, or reference, for my job as a product marketer.

Mammoth allows you to create ‘boards’ which store the content about a particular subject. Boards can be shared so that people in different locations can edit the content collaboratively. A standard board in Mammoth is ‘Talk to Us’, which is shared with the Mammoth support team, and this allows me to address any issues I have with Mammoth online. Whenever I have logged an issue, I get a response via the board usually in a few hours.

In one case, Mammoth made a change to the user interface (UI) which made it look worse for me, so I logged a note on the Talk to Us board. There was a bit more discussion and clarification about the UI issue on the board, but what interested me was that 24 hour later when I logged on to Mammoth, the UI problem had been addressed. The application was fixed and changed without me having to do a thing.

It made me re-evaluate my view of cloud-based services.

  1. A problem with an on-premise application always requires the user to do something to fix it, usually download and install a software patch. With a cloud service, the problem is fixed once in the cloud, everyone gets it at the same time, and new software has to be installed.
  2. A problem with on-premise software is reported either by a phone call or an email, which then has to be discussed and confirmed before it can be transcribed and referred to the software development team. With a cloud service, you log an issue online in one place, the issue can be quickly confirmed and then be relayed speedily to developers.

Imagine if you could do that with enterprise software – ERP, CRM, warehouse management.

  • Customers could report problems so much quicker, and probably have a better support experience
  • No need for each customer to update the software with maintenance releases to fix bugs
  • Customer could log enhancement requests in a more effective way, and perhaps even get previews of enhancements before they go live
  • The development team work on supporting one codebase, in one location, for everyone
  • No need to ship CDs of software around the world

Wouldn’t that world be better? Oh wait, it’s called Software-as-a-Service and it’s here already.

The problem is that while the promise sounds simple and wonderful, the realities of transforming to that promise require major changes in thought, approach and practice – and moreover, for traditional software vendors, major investment expense.