working on the bizI have long considered the CEO’s number one task to be that of working ON the business, rather than IN the business whenever possible.  It’s not always possible, but it’s possible more than most CEOs and small business owners think.  It’s a principle I’ve abided by for the nearly 28 years I’ve been at the helm of this software company, and many of my colleagues and fellow business owners know that about me.

In fact, I take a fair amount of good-natured ribbing over my ‘inferior technical skills.’  Truth be told, I was a highly-technical-PC- guy a good many years ago.  But I dropped the mantel of the wizard and the Cult of Personality shtick a long time ago in favor of trying to do one thing well… just manage the business.

In other words, work ON it, not IN it.  So a recent article espousing that very philosophy written by the folks at Panorama Consulting was music to my ears.  In it, we are reminded of a book you may have read quite a few years ago called The E-Myth Revisited, in which author Michael Gerber first articulated this challenge, now so familiar to so many CEOs and entrepreneurs.

Panorama provides a succinct summary: “To summarize the general dilemma: executives at organizations often get consumed with “doing” the work rather than “building” a business that enables the work to get done. ”

So, if a business has not structured the right business processes… if it hasn’t managed its workflow into repeatable patterns… it hasn’t defined roles and responsibilities… it’s more likely to suffer from the stresses that stem from a lack of clarity.

Especially as organizations grow, owners who have focused more of their time working on the business tend to suffer through fewer crises and can often minimize stress and confusion.  Businesses can run more smoothly and predictably when roles and responsibilities are well established.  Less time is spent putting out fires and a little more time might be expended on planning for the future.

So, what does all this have to do with ERP?  If you’re a “mature” business, with a focus on growth, probably a lot.  The ERP system is a foundation for being able to focus on the business, instead of working in it.  ERP creates consistency of process and procedure, augmented by the speed of computing, that enables profitability and scalability – key components to growth.

Of course, that only works if the managers of the business have used the process of implementing ERP to evaluate and reengineer the underlying workflows that the system is intended to manage.  The way you get to scale and growth is through repeatability.  Planned and executed properly (and only then) ERP fosters repeatability.

It all starts with analyzing processes.  That usually leads to business process reengineering.  Then, in order to actually succeed at this, the company must embrace organizational change management, establishing clearly defined roles and responsibilities, clear communications and expectations, and a few key performance measures.

Only then are companies in a position to actually implement the (ERP) system that will put them on the road to repeatability, scale and growth – and thereby free the owner to work even more on the business, than in the business.

Or maybe, on the golf game.



who what whyIn our last post here we looked at a simple model called the User Story that can be employed to help ensure that what a customer needs their software to do becomes, in the end, what it actually does.  If you’ve read the simple basics in our prior post — with emphasis on the User Story’s Who, What and Why — then our example today should help seal the deal.

Our example comes from an actual client with a need to which most companies can relate.  Our customer produces products requiring multiple steps and assembly processes for the RV and marine industries.

Who:  The ‘Who’ is our client’s General Manager.   The GM is responsible for ensuring that production on the floor runs smoothly and efficiently, ensuring that work crews across the various production zones are being utilized as effectively as possible.

What:  The GM wanted a custom report that would give him sales dollar volume currently sitting in customer orders, arranged according to each order’s work center on the floor.

Why:  Like other companies, our GM uses order backlog as a proxy for more detailed production and work center/routing cues.  That makes sense because it’s a great ‘seat of the pants’ barometer for how busy the folks on the floor are likely to be in each area of production.  They want to look 3 days out and know how “balanced” the flow will be on the production floor.  (Or in production floor parlance: Which butts to kick, right?)

So in simple terms: The GM (Who) needs a specifically filtered report based on orders (What) in order to balance the workload on the shop floor (Why).

The value lies in being able to keep promise dates, keep the floor busy, optimize production, and maximize throughput while minimizing labor costs.

Some experts, like the development team at Rally Software Development would say that this User Story gets us started, but the team needs more: they need the 3 elements of a user story – the Card, Conversation and Confirmation.  That’s pretty easy too…

The Card is the overview of Who, What & Why — using an index card as a metaphor (and sometimes literally) as the space for telling the succinct story.

The Conversation results when the Card is used as the basis for a discussion between the client and the provider, as they develop a shared understanding of the desired functionality, goals and constraints.  Here the consultant should be asking questions to ensure a clear and mutual understanding.

Finally, The Confirmation should be captured after the Conversation, in the form of “acceptance criteria.”  In other words, how will the results be tested to ensure the need (What, Why) is met?  How will the customer confirm that the story was properly implemented?  The acceptance criteria are the conditions of satisfaction that confirm that the user story has succeeded.

That’s it then: Who, What Why… and the 3 elements of Card, Conversation and Confirmation.  The User Story can go a long way towards ensuring a successful implementation is occurring at each step along the way.


user storyA good technique much discussed in software development circles (and around our offices of late) is the “User Story.”  It’s a simple but effective method aimed at capturing what a customer or user wants to achieve through their software — about getting to the business case.  By having the user convey their wishes to the software provider in this manner, it is possible then to derive exactly what features they require and, perhaps more importantly, what benefit(s) they seek to achieve.

The idea, as a recent article produced by a company called Rally Software Development denotes, is to “provide context.”  It helps your consulting partner to understand your real, underlying need and thus better enables them to implement the functionality that you, the user, have in mind.  It’s particularly useful for tasks like creating reports, modifying workflows and executing software modifications.

The User Story typically features a Who, What and Why. (Our image today, a Dilbert cartoon, is only one way of looking at user stories, thankfully.)

The Who of course refers to ‘who’ wants the desired functionality.  The idea is describe which customer or user benefits.  You seek a richer understanding of the person’s needs and motivations, so you want to keep this part as specific as possible.

The What specifies the need, feature or functionality that the ‘Who’ desires.  This is what needs to be built into the software or report or process fix to be provided.  It needs to be crystal clear – often involving a fair amount of questioning and back-and-forth dialog – in order to ensure that the team knows what to build.  When software modifications or reports are the basis for the What, it is particularly important to convey all the necessary details.

The Why specifies the underlying ‘value’ to the Who.  It’s the reason for the deliverable in the first place.  Why do you want the software or process to work this way?  The Why often gives the story, or as the folks at Rally Software point out, “its richness.”  It helps the team design the solution that meets the real needs of the user.  Also, in today’s more ‘agile’ development arena, the Why keeps the value front and center.  It is a way of restating and reemphasizing, in an ongoing manner, the business case that brings the actual value or ROI to the customer.

In fact, if you cannot find a Why in your User Story, you might have a story with no value.

In our next (and concluding) post on User Stories, we’ll give a real-world example of a User Story and look at a few cues that help ensure a successful outcome.  Stay tuned…


corfu_roadmap_imageIt’s far too early to know very much, but what we do know about the next release of Microsoft’s best-selling Dynamics NAV software we’ll share below.

The new product, code named “Corfu” for now, is slated for release in “late 2015.”  We’re guessing October, based on past experience.  An engineering director for the NAV product announced at the firm’s Tech Days conference a couple months ago that Corfu will introduce new baseline capabilities around three functional areas: workflow, document management and OCR, and E-services integration. He described E-services as the trading of electronic documents with other parties and the mapping tools required to transact them.

The development team continues to work on a single (programming) code base (for the client side of NAV, not the source code that runs the application) across all user interfaces: mobile, web and the desktop clients.  The web client may even surpass the capabilities of the role-tailored client in the next release, according to one Microsoft engineer, as they improve the web client performance and responsiveness.

Microsoft continues to use an “agile” approach to development, which in lay terms can sometimes mean more releases, faster.   That approach can also make predictions about the future NAV roadmap – those beyond a year anyway – a bit harder to pin down.

One encouraging future “maybe” that was discussed was the ability to create “event-driven” customizations that would consist of a series of hooks that would allow developers to work with the base product less intrusively and help “future-proof” customizations.

Other updates under consideration for Corfu include updates to document reporting, to the C/Side development environment, improved Office 365 integration, Rapid Start enhancements, and various NAV client enhancements.

We’ll provide more info in time, as we ourselves learn of any new NAV developments.


conexus_logoIf you are an Indiana based manufacturer, you’ll want to know about this.

Conexus Indiana is a workforce initiative funded by the state of Indiana aimed at helping manufacturers find and align resources, take advantage of procurement opportunities and generally advance the state of manufacturing in Indiana. They’re supported by major universities like Purdue and Notre Dame, as well as many major public manufacturing firms.  We’ve recommended them previously for their handy supplier opportunity postings, where firms can get insights about who is looking to buy what.

In their most recent newsletter, Conexus Indiana announced a program that will help companies start high school internship programs in their firms.  They will even provide the funding for up to 80 interns across central and northeast Indiana in 2015.  You can learn more about this new program at the Conexus website here.

As the Conexus website states:

“The State of Indiana awarded Conexus Indiana an Innovative Curriculum grant to launch an advanced manufacturing and logistics (AML) high school internship program which is fully compliant with state and federal insurance and labor laws.  This program uses an industry-driven framework that allows for broad-based implementation across Indiana.  Called the “Conexus Interns Program,” the goal of the program is to convert current advanced manufacturing and logistics (AML) students to employees or post-secondary student in the AML field.”

The application can be downloaded here.

Interested manufacturing companies can also call Tracey Everett at Conexus in Indianapolis at 317-236-6275.

We think it’s a great way to acquire and start training your future workforce, and encourage any interested readers to contact Conexus directly if you’re looking for an intern or two this summer.



bprWhether you’re looking to improve your customer service, improve your top line or increase your bottom line, companies seeking improvement have plenty of reason to reengineer their processes.  Usually, all of the above.

So when a firm takes on the task of implementing an ERP system, business process reengineering is – or should be – the key motivation.  That’s often coupled with a desire for growth, or the ability to handle growth already upon them.

A recent 2014 ERP Process Improvement Report from Panorama Consulting showed that 100% of respondents had suffered some sort of “material operational disruption at the time of go live.”  Of these, 60% lasted at least a month.  Nearly two-thirds said they expected some difficulty in adjusting to operational change.  Interestingly, fewer than half “changed their business processes [in order] to leverage functionality of the new ERP system.”

We ask: Why do it, if not to review, analyze and ultimately change and improve your processes?

Well, as it turns, one key reason is budget and timeline overruns.  The challenges of the reengineering that motivated acquiring the new ERP system in the first place appear to cause companies to neglect the very reason they went there in the first place: process change and improvement.

In other words, it’s harder than they thought it would be.

Panorama suggests three things to keep in mind to ensure that you achieve the best business process reengineering results possible:

  1. Recognize that not all your business processes are created equal. The short version: Prioritize your process improvements, and then focus on the handful that brings the most bang for the buck.  Push the others to the back burner when necessary.
  2. Integrate your business process reengineering and organizational change management activities. Don’t treat these as two separate activities.  So for example, the people defining the new processes should also be the ones defining the impacts on departments and people.
  3. Ensure your project plan includes enough time and resources to properly account for business process reengineering. Most teams don’t ignore process work because they want to… they often simply don’t have enough time (or didn’t budget for enough) to address this on top of all the other important project activities.  Start with a realistic plan and budget that accounts for process evaluation and retooling, and you’ll be an order of magnitude ahead of most ERP implementations right off the bat.

There’s the gist of it, and we couldn’t agree more, based on our own observations of many years.  The rest of the article author’s thinking can be found here.

LeanCartoonRichard Schonberger is the author of over a dozen books on Lean, Six Sigma and process improvement.  In the most recent issue of APICS Magazine he casts an important reminder about what lean is really meant to be, and how often it’s confused.

As Schonberger points out, “… people tend to forget that lean is inherently strategic and a matter of –time-based competition [italics ours].”  Too often, he notes, a lean initiative will start as a major company initiative with full senior management involvement.  Then, as the initiative gains ground and moves into what he calls ‘operational silos’ lean often transforms from its roots in “time-based competition” into merely a means of waste elimination, or some internally-focused efficiency program.

And at that point, ‘internal efficiency’ takes precedence over the more critical customer-focused effectiveness that lies at the heart of lean.  As a result, it often becomes disconnected from other parts of the company such as finance, marketing and sales – too focused on efficient instead of effective.  The author aptly likens this to the grocery store that has plenty of folks stocking shelves but not enough at the cash registers.

Schonberger reminds businesses that a lean shift needs to take place that redefines and promotes lean as time-based competition.  “That term should populate company walls and documents,” he suggests.  All other lean terms should remain intact, but “be subordinate to the main themes of time and the customer.”  It requires a dedicated campaign.

The key is a launch that promotes the Whys and Hows of tapping into lean’s large potential for dramatic competitive advantage.  Each success, he says, “should show up quickly and convincingly – first as reduction of channel inventories(*)  and, before long, in winning more customer orders and retaining good customers longer.”

Finally, he notes wryly, success appears as a sign of trouble for one’s competitors.

(*) For more insight on the Hows of reducing channel inventory, you need to read the entire article (it’s not terribly long) on fast setups and changeover, delivering quick and flexible response, and perhaps most important of all, having a multi-skilled workforce.  The full article (Catching Lean’s Drift) can be found in this month’s APICS Magazine (Jan/Feb 2015).  Consult your local APICS chapter for more information.


Get every new post delivered to your Inbox.

Join 100 other followers