Thinking Tech

Computers don't implement anything in general...and neither do programmers. But we business folk tend to think in generalities. Someone might say, "Put the cost in column 3." Seems simple enough. Until you start to try to calculate cost. Which cost? Last cost? Average cost? FIFO cost? Cost including freight or not? Cost including handling and warehousing charges? What cost? There are a lot of costs.

When I ask these questions of some clients, they get frustrated. It's as if I'm trying to pin them down. So the typical answer is something that evaluates to, "I don't care, just pick one." So we do. And then....

It is terribly important when you talk to computer folk that you think in specific. Computers have to think in specific. Over the years, I've worked with perhaps a dozen or so off-the-shelf computer software programs that dealt with inventory. Pehaps a dozen or so more that were custom written. Most of these implemented the details of inventory cost differently. Many of them differed in how they made the General Ledger entries. Some of them reported different numbers on financial statements than they did on management reports (for very good, well-thought-out reasons). But all of them implemented very specific processes for determining cost. And it was important (ultimately) to understand the details in order to figure out what they were doing.

Let me say that as a CPA and a programmer, I have trouble saying that some of these were right and some were wrong. They were different. I could argue for all but a few being appropriate. But I had to understand the details to understand what I was seeing in reporting and on financial statements.

When we ask detailed questions or seem to bog down in meaningless drivel, keep in mind that we're just trying to get to the best result for everyone. And try to think specifics...

Much of the work I do is with companies that are replacing their accounting and operational software. You hear it called a lot of things, but the most common industry term is ERP (enterprise resource planning) software. As I've written somewhere (maybe here), this includes accounting, inventory, order entry, purchasing, manufacturing, sales, marketing (CRM), service, and other software required to plan the "enterprise."

Clients often begin our initial meetings with a list of "what they need." It might sound something like this: "We have Software X, and it won't do A, B, and C for us." Sometimes the software is too small for the company (they have outgrown the features), sometimes the software is old, sometimes it never really worked and the issues have simply become overwhelming. At least part of the time, the software has been custom written. But whatever the reason, they're moving on.

I tell clients, "We treat cancer." In 20 years in this business, I've never had a client come to me and say, "Bob, we're looking for new software. We don't have any real problems, but it's been 5 years since we replaced our accounting system and we think it's time to get something new. We just think it's time to stir everyone up, retrain everyone, make all the resistant to change people in the organization mad, and generally create chaos."

No, they come to us and say, "We need A, B and C." The problem is that what floats to the top is often only a part of the whole need for the company. If the company makes the mistake of buying software based on this type of an analysis, it's not uncommon to have a great deal of trouble making the change. Basically, a key set of needs is ignored.

This is one of the big reasons that I've begun to do Needs Analysis in the last year or so on ALL new clients. Because I'm serious about "The right direction, the first time," it's important for us to get all the needs. And the only way to do it is to do a needs analysis. Take a look at our process for selection of ERP software.

Microsoft bought four products from the mid and upper market ERP space: Great Plains, Solomon, Navision, and Axapta. Since then, the products have been renamed to Microsoft Dynamics GP, Microsoft Dynamics SL, Microsoft Dynamics NAV, and Microsoft Dynamics AX. Most people remember that about three years ago, Microsoft also announced "Project Green." The idea was that--eventually--there would be a single product that combined the features of all of these products. Originally, it was to be available sometime around the 2007/2008 timeframe, as I recall (could be wrong on that one, though).

That's been three years or so ago. And even then, the industry experts in-the-know doubted that it could be done in the timeframe that Microsoft envisioned. Today, the word has been out for 2-3 years that Green won't appear until at least 2011.

But, with the preliminary information available on version 5.0 and 5.1 of Dynamics NAV, the strategy seems to be coming into focus. The key is to preserve the existing product investment in functionality while at the same time migrating to an environment in which all of these features can play together in the same sandbox.

The sandbox, as many of us anticipated is IIS, with SharePoint sitting on top of it.

And--I have to say--the preliminary versions look pretty good. Keep tuned for more information about role-based user interfaces, and new features as well as the progress toward the end result.

Microsoft Dynamics NAV product overview

Didn't meet Mark at Directions 2006, but he does have something to say about 5.0/5.1. Everyone's opinion is valuable. Here's another one for you to consider.

Mark Brummel : Reporting from Directions 2006

I have trouble calling it Dynamics NAV. To me, it's still Navision. And version 3.6 was new when I first learned Dynamics NAV a few years ago. It's time for the 3.x versions to be retired, and Microsoft is doing just that with version 3.7 on November 12, 2006.

I know software companies have to discontinue support for old versions. I understand that it's just not practical to continue to support versions that are even a few years old. And--practically speaking--it really doesn't mean anything for clients. They can continue to use the old version. But eventually it catches up with them. Eventually, they have to update because the technology gets so old that it's not compatible with current technology, or won't work with the current version of something.

The bad thing from my perspective is that it leaves us in the middle. Clients want support for software the vendor doesn't provide backup for. Like trying to repair washing machines when there aren't any spare parts. Well, it's not quite that bad...software generally doesn't wear out...but eventually, it won't work with current operating systems, hardware, etc.

Unfortunately, when the day comes that the software has to be retired, the software vendor is isolated from the situation, and our client feels like they are being forced to upgrade. And Data Guidance Group catches the angst. It's OK, though. It's just part of the business. I wish all software for our clients could be low cost or no cost.

Of course, most software vendors would argue that software already is...

This is the time of year when businesses seem to think, "I meant to do this all year, better hurry up to get it done by year end." I know this because businesses we've been working with since January make a decision to move forward.

If you're thinking about an implementation, you'll need to move forward in the next few days for a 1/1/07 go live date.

Microsoft reps announced a number of forthcoming features at the Directions 2006 conference. I've been back for a couple of weeks and am finally hunting up my notebook to relay a few tidbits of information. None of this, of course, is officially in any shipping product, but some of it will probably make it into the next version.

Interesting Feature 1. Sales and Purchase order approval. That is, you'll have the ability to direct purchase orders and sales orders to employees for approval. Approval can be delegated and employees can make comments.

Microsoft is not calling this workflow, but if it's not, it certainly sets the stage for it. That would also be consistent with the overall direction of leveraging the strengths of all the products in the Microsoft "stack." The Microsoft stack refers to the Windows Operating System, SQL, Exchange, SharePoint, and the other products generally referred to as "traditional" Microsoft products.

See the entry on VaporWare (posted on purpose before this one.) Another way of saying, "Don't count your chickens before they're hatched."

NAV 5.0 rumors...rumors only, mind you.

The jobs function of NAV will finally get some reworking. Better support for budgets. Support for fixed price jobs. Some other new stuff.

More later...

Will 5.x be .NET or C/SIDE? It's hard to tell exactly what Microsoft is going to do with 5.0/5.1. Version 5.0 will definitely be a C/SIDE interface.

Last year (2005) at Directions, they announced that the development tool would be exclusively .NET, with extensions to handle the accounting-specific stuff. This year they announced that they have moved away from that.

The description they provided for the 5.1 release basically indicated that there would be a 3 tier structure. Tier 1 would be SQL (required for version 5.1, the NAV native database will go away in that release). Tier 2 would be the business logic, which would still primarily be in C/SIDE. There would be translators to move things like forms to C#, where they would be compiled. There were a good number of questions from VARs about what the ratio of .Net to C/SIDE development would be. Many were concerned that C/SIDE seems to require different skills from .NET. Also, questions were concerned with ease of modification, particularly for simple mods like adding fields.

In 5.1, the whole thing will sit inside SharePoint Services.

Overall, the strategy for 5.1 seems to be to preserve much of the core logic in C/SIDE, while allowing a migration of the UI to C# and .NET. I think that's an excellent plan, from the technical side. Likely to produce a product that looks good and is stable quickly after release.

The issue (which came to mind several times) was what this would do to migration for clients that have extensive customization. To the questions above, the most common Microsoft answer was, "Too early to know for sure."

It says something that exactly ONE technical (programmer) person was allow to leave Denmark for the conference. All the rest had their little (maybe big. What do I know?) noses to the grindstone working out the final bugs in 5.x for March 2007 release.

Demos of 5.0 looked basically like 4.0 in UI. 5.1 is "role based," and the only "role" they showed was "salesperson" or "order entry person." The 5.1 demos were clunky and looked cobbled together to show us the look and feel. We are supposed to see pre-release 5.1 stuff with the 5.0 release in March, and I think we'll know more then about how close MS is to having something. I don't expect to see the migration toolkit or any hint of what's really coming in that before the actual launch, and think there will need to be significant planning before any migrations to 5.1 occur. To my eye, there are still some rough spots in 4.0 (for example, the report margin problem in SP2, quickly fixed by the .EXE in SP3.)

All in all, however, 5.1 looks good from a user experience standpoint. It clusters the most common tools for a task on a single pane, and allows for development in .NET, C#, etc. I'm actually looking forward to it, but we have significant .NET development experience, not just C/SIDE. I can see how it would frighten a shop that had only C/SIDE experience.

Jeff Kugler makes a great point in the article below. He says you shouln't modify ERP software. I agree. Since you can read the article for free after you register, I won't repeat the entire argument. Since you have to register, I'll repeat the key points.

Here is the key thread of the argument:

• ERP software is developed according to best practice standards derived from groups like APICS (manufacturing trade group), and large businesses


• Other features are added because businesses request them, and are selected based on the number of businesses that request them


• You spend less money implementing if you don't modify


• You implement faster if you don't modify


• Therefore, never modify

Problem: Jeff isn't living in the real world where businesses (and people) are resistant to change. He doesn't account for the ERP systems that would never be implemented AT ALL if they were not modified because the users would reject them.

Problem: Jeff is about two years late. We've been telling clients this in our kick-off meeting for at least that long. Some clients listen. Some do not.

Problem: Sometimes modifying software is a competitive advantage. It increases efficiency, productivity, and throughput.

Solution: Minimize the changes in implementing ERP. Delay as many as possible until you've used the software the way it is designed to work for at least 3 months. After that, you'll be in a better position to decide what you need to modify.

My $0.02.

Impartial Enterprise Software Evaluation, Comparison, Selection Research and Tools for IT Executives. ERP, CRM, SCM, PLM, BI, BPM, HR, Financial, Open Source, Outsourcing. etc.

I visited with a client that was thinking about buying new software last week. They had a pretty good idea of what they wanted, and I was there to ask more questions to make sure I understood all the detailed needs.

In selecting new software, it's important to define all the needs. Businesses tend to focus only on the things that are immediate problems. That is, on the statements that begin, "It won't do..." or "We need to be able to..." It's important to gather this information, of course, but there are also a large number of things that fall in the category of statements that begin "We like the way we're..." For more on this, check out the post on The Gladys Principle.

Anyway...

As we were leaving, the client introduced us to the "IT guy" who started with the statement, "I have a few questions I'll need answered."

"For example?" I asked sweetly.

"What database does it run on? Is it web ennabled? What administrative rights are required on the server? Blah. Blah. Blah." In other words: Cost doesn't matter. What the software does doesn't matter. All that matters are the technical parts.

Reminded me of the guy that wanted software written in a language he knew. Also wanted the source code so he could modify it. He found some. Last time I heard from him, he had sued the software vendor to get his $75K back.

Doing it this way is like the carpenter that only had a hammer, so every problem looked like a nail!

Rule #1: Don't worry about the technical stuff until after you've found the software that does what your business needs it to do.

The technical stuff should only matter when you're comparing products that you know have the features you want and are trying to make a decision between them.

I'll learn new technical stuff every time if you give me the business features I need.

Hopefully, if you're looking for new software, you started with a thorough needs analysis. Not just what was wrong with your existing software, but what your total needs were.

I used to teach consultants how to do consulting. One of my points was, "Have a checklist." I had an illustration of this point. I had one of the class members choose a card from a deck of 30 index cards. On the card was an animal, vegetable, or mineral (you remember the old game of 20 questions, right?). The idea was for the class to ask one yes or no question at a time (with the question, "Is it an animal, vegetable, or mineral?" specifically allowed), and to figure out the answer.

After about 3 questions, the game degenerates to trying to guess the thing. "Is it a zebra?" "A willow tree?" "A rock?"

The 20 questions are soon up, and the game ends.

Then we played the game again. This time I gave the class a decision tree. It had about 8 or 10 questions on it. Each question said, "If the answer to this question is Yes, go to question x. If the answer is No, go to question Y."

It never failed that they would get the right answer, usually with about 4 or 5 questions.

"But that's not fair," they would complain. "You knew the answers when you made up the question."

Right. And what kind of consultant would I be if I didn't have a pretty good idea of what the range of answers was for solving a given business problem? Sure, I'll run up against problems that can't be solved with my questions (just like you could find a card that wasn't included in my 8 or 10 questions), but at least I'll know when the answer is outside what I'm used to...and I can respond accordingly.

So...the point is...you need a checklist, a list of questions, something to start with in order to do a needs analysis. My list of questions is about 30 pages long. I don't ask all of them for every needs analysis...some companies don't need inventory or job cost or service. But my questions cover the field on which I play, and I add to them on a regular basis to account for new management techniques, or new players in the game.

Rule #2: Start with a needs analysis based on a plan of attack, which most of the time will be an outline or a list of questions.

Document the answers. The result will guide the rest of the process of implementation.

There are sites on the internet (like FindAccountingSoftware) that collect information from people looking for new software and feed it to people that provide software.

If you looked through the list of "projects," you'd see a lot of them that want General Ledger, Accounts Payable, Accounts Receivable, Payroll, Inventory, Order Entry, Purchase Orders, Manufacturing, Service, and CRM. They want complete training and support. And the budget is $5000 for 5 users.

Or they're looking for a new real estate management system with a budget of $2500 for the entire project.

Or a new inventory system for $500.

And these projects sit and sit and sit. No consultant or software provider volunteers to contact them. Why? Because it's not possible to provide for their needs for the price they have set.

I've talked to the FindAccountingSoftware people about this. "We try to get them to set a realistic budget, but some are just convinced that they can get something for nothing."

Several years ago, I got a call (for the second time) from a local business. The first time around, his budget had been $10,000. He was looking for hardware and software and implementation and data conversion. Ultimately he bought a system for twice this from a company that (from the looks of it) my have sold 25 copies of the software.

He got a deal.

Problem was, the software didn't work. Inventory was wrong. You could run the same report twice and get different answers with the same questions. I know what you're thinking...you must have put in the wrong dates or something the second time...nope...been around long enough to look for that. The same report gave different results.

So we did a needs analysis (see #2). Good step.

Then we talked about budget. This time, the business fellow figured he could go as high as $20,000 for 13 users.

"Sorry, I can't help you," I told him.

"We'll find something," said he.

"You did last time!" I reminded him.

Realistically, there are three basic ranges of software. Low, Middle, Tier 1. Some people put in another one, but I'll stick with the three: S, M, L.

Tier 1 (L) packages are going to cost in the range of $500,000 to a heck of a lot more than that for businesses the size that need them. And the implementation will probably cost at least twice that.

(Ok, the Tier 1 vendors can point to some exceptions on the low end, deals where the software cost $100,000 or $150,000, and where the implementation was $50,000. But for the average business, you wouldn't be looking in this range of software if you didn't need about 50 or so users on the low side, and that's going to cost you).

Figure $5,000 per user in this range, at least. And twice that to four times that for implementation.

Next I'll take the low end (L). That's where QuickBooks lives. And Peachtree. Figure about $700 on the high side per user. And the software's so simple that you probably won't need much help figuring the software out. You may need some help with the accounting concepts, though. That's where an accountant or CPA comes in.

And now for where most people live. Usually around 5-10 users, companies figure out that QuickBooks or Peachtree or custom software or Excel or ACCESS aren't working any more. They start looking for software for their businesses. And they have two basic choices: off-the-shelf, general market software (what I call the "Top 10 Mid-Market Packages." Even though at any given time there may be 8 or 25 of these packages, I still call them the top 10) and vertical software.

And since discussing the differences will take a while, and this entry's long already, I'll stop here with the note that these packages are going to run in the range of $3000 (basic model Chevrolet) to $10,000 (limo) per user. The difference is the features you need and how many users you need. The fewer features, the less the investment. The more users, the less the investment per user.

And--lest you start thinking this--you can't often just "give up features" to lower the cost per user. Most businesses that need inventory or a web store find that the cost per user is rising and they can't find much of a way to push it down.

More later.

Many clients like the idea of "do it yourself" software implementation. After all, industry studies show that between 1 and 4 times the cost of the software is invested in services (customization, implementation, training, etc.). Saving that money looks pretty good, and sounds even better.

In reality, ERP software is complex. It generally takes one full implementation for someone to figure the general functionality out, and several more for a consultant to begin to understand the true abilities of the software. This is in addition to weeks of training and staffing the call center. Until then, there are many mysteries in ERP software. How exactly does pricing work in this scenario? How can you get the sales tax report to come out like you need it to come out for TN sales tax? Is it possible to calculate TN sales tax (including the 2 tier, $3200 per item limit) with this software? Will that even matter?

When you get into specific features, you need to understand both the business and accounting implications of things. What exactly does backflushing do? What if I use LIFO and backflushing? How are items relieved from inventory if I purchase them and tag them for a particular job? Do they go through inventory? Do they affect average cost? And on it goes...These things are only learned through years of experience...even knowing to ask the questions, or that there may be issues requires experience.

And then there is the matter of add-ons and customization and modification. All-in-all, it takes years of experience to understand ERP software.

If I'm ever responsible for implementing ERP software as a CFO or CEO in another company (and I plan to be at DGG for a long time; someone else needs to clean out my desk), believe me I'm hiring a consultant to do the dirty work. And the first questions I'm going to ask are: How long has the lead consultant been implementing software? Will I be able to get hold of her or him when I have a question, no matter how simple? How long has the least experienced person I'll be working with been implementing software? How closely will that person be supervised? Do I have an option to pay more to get a more experienced consultant if I want to?

I've seen a few companies do-it-themselves. Generally, they spend more trying to straighten out the mess later than they would have spent getting assistance in the first place.

Kinda reminds me of that time I was going to paint the house....

In the 1980s when I was in college, an article came out in one of the leading journals describing technology projects as a process of "unfreezing," "change," and "refreezing." I've found this image useful for what DGG does. In most businesses, there is at least some element of resistance to change. Often, I see businesses that delay needed Information Technology changes until the last minute, then expect them to proceed without a hitch.

Reality intervenes in these cases.

I've written somewhere else that 10 years ago software was behind business. If we got a 75-85% fit for needs with off-the-shelf software, we were doing pretty well. Now, with the advances in hardware that make extensive software optimization unnecessary, and the advances in software development tools and techniques that allow quick development of complex software, it's possible to quickly add features to software. So software--in many cases--is ahead of the business...it does things the average business doesn't need to do today.

And therein lies the opportunity and the danger.

The opportunity to become much more efficient by applying best practices to the operation of business. And the danger that the change will be too difficult to absorb.

Make sure your business is thawing before you begin a software project...it will go a long way toward ensuring the project's success.

What process will you use for selecting your software? Let me describe the typical process I've seen:

• Make a list of the things you don't have now or don't like about your current software.
• Identify possible packages
• Call the vendors of the software for demos
• Review the demos
• Get together with staff to discuss the demos
• Select the software based on the demos and price--particularly price, since by this time most of the software will have started to look and sound the same.
• Begin to implement the software.
• Wonder if you made the right decision.

This is the process that most businesses seem to use. It has a several issues:

• The only needs identified (first bullet) are things that are wrong with the current software. Things that are right with the current software are ignored (see The Gladys Principle post).
• The vendor generally controls the demo. Only things that work well will be shown.
• Proposals are rarely apples to apples.

If you do things this way, I can just about guarantee you that you'll select the software vendor with the slickest presentation rather than the best product. If you don't want to do that, use a process that includes a needs analysis and a review process that evaluates your needs against features rather than vendor against vendor or (more likely) price against price.

My rule of thumb is 1,000.

It takes a thousand items to make a conversion really worthwhile. Less than that, you might as well hire a temp and have them key the data. That's 1000 of anything: Customers, Vendors, Items, lines in a bill of materials, ship-to addresses, open orders, etc. If you've got more than 1000, convert it.

If not, key it.

Why?

Well, briefly put, if you're moving from one accounting product to another, you can guarantee that the files don't look the same. They have different options. The item description is 40 characters in one and 30 in another. The item number can be 10 characters in the old and 22 in the new, or vice versa. And under the hood, in the database, they are called different things.

This means that conversion from one product to another--assuming that there's not an automatic conversion already built in--means writing a program, or at least building a map that says "put this data...over here." So there's always programming involved.

And 1000 items seems to be the break between when it's cheaper and better to code it vs. key it.

Just a rule of thumb, though.

I should probably add this to the list of things you should (or shouldn't do) when selecting software. It's part of the standard way businesses go about selecting software. It works something like this:

• Find 12 companies that sell software that looks like it might work
• Call all 12 of them
• Start research on the Internet about the software. Print out everything you find of interest, whether it's one of the 12 software companies you called or not
• Add all the new companies to your list, and call them
• Talk to the first 8 or 10 that call, and request a demo
• Accept the offers to demo on the web
• Don't take notes
• Don't have a list of questions to ask
• See the other demos either on the web or in your office over a period of 4 or 5 weeks
• Realize that you should have been taking notes and start after the 2nd demo
• Make a list of notes about the first 2 demos so you can give them fair consideration at the end of the process
• Since some of the software companies will call after 2-3 weeks, pack in 2 demos per day in the last 2-3 days of the period before the deadline
• Call a committee meeting the day after the last demo
• Reschedule the meeting because a key employee (who could only attend 25% of the demos can't be there)
• Reschedule again...same employee
• Reschedule again...
• Finally, insist on a meeting and have it
• Make a decision to call back the 3 possible vendors you liked the best
• Be disappointed at the second demo...it seemed like those products did more
• Make a decision based on the best presentation of the 3
• Document, document, document the process so management will see that it was thorough, thorough, thorough
• And now....?

Does this sound like a process you've been through?

More tomorrow on what the best practices look like.

The #1 problem with getting software demos early in the selection process (or as a replacement for the selection process, in most cases) is tunnel vision.

Software vendors train software resellers to demo only those features of their product that are (a) strong in relation to competition, (b) work well, and (c) are flashy. This biases the selection process in the direction of the features that look the best to the committee--even if it's a committee of one.

I've seen too many businesses select software that I knew would not meet their needs because they got tunnel vision. They focused on a few features that they didn't currently have to the exclusion of features they needed. It's one of the key things I wrote about in the Guide To Selecting Business Software. It's the key reason for having a selection process that includes needs analysis.

The #2 problem with getting demos to select software is that most demos aren't driven by the needs of the company trying to select software.

Don't get me wrong--a demo is an important part of selecting software. But not a demo of the features that work best in that particular software.

Demos--if they are done--should address (primarily) the key needs of the business. Here's an example:

Several years ago, I spoke to a company that wanted software to control the delivery of their service. It would take the particulars of the (sometimes very complex) contract and manage the delivery of the service (which many times involved coordinating a number of different activities over a period of several months). The company was known for providing very personalized service (knowing names of family members, etc.), and the idea was to support not only the service side, but the scheduling and delivery side.

I didn't participate in the demo, but the only demo that would make sense in this case would be a simulation of the contract delivery support the system can provide. Specifically, I'd want to see

• Setting up a contract
• Setting up the parameters (contacts, family member names, etc.)
• Simulation of several of the common scenarios (from both the customer service and the operational side of the business)
• Opportunity to address several unusual "what-if" situations
• After all of this, I might have questions about accounting, export to Excel, Access, and Word, and the database backend. I might even want to look at the report writer and the database structure. If I planned on customizing the stuff, I'd want to see some of the representative code (I'd pick the functional area of the program and the function I wanted to see code on.) BUT (and this is a big but)...I'd want the answers to these questions ONLY AFTER I was convinced that the software could meet the needs I'd expressed in the needs analysis

Of course, this assumes that there WAS a needs analysis.

Before I go, one more thing. I got the NAV 5.0 beta this week. It was in the February newsletter available for download. I didn't read the newsletter until Wed., but I've got it now. I also printed the training material for What's New in 5.0.

I'm taking Part I of the What's New home this weekend. I'll let you know how I fare.

Microsoft Dynamics NAV 5.0 beta is out and about, along with the "What's New" training manuals. There are two volumes of training designed for dealers and implementers, but the basic information should be available on CustomerSource as soon as 5.0 actually starts shipping.

5.0 is expected to ship the first part of April (perhaps the very end of March). Nothing is out yet about whether the first shipments will contain the conversion kit necessary to move users from previous versions to the new version. The basic look and feel is about the same as 4.0, but there are about 500 pages of training just on the new features.

There are three that I've picked out from Volume I of the Whats New training (which I've finished reading) to discuss here. I also have some comments about the implications of some changes that are occurring in the development tool.

Here are the first changes I'll talk about:
(a) Outlook integration which is much improved and fully customizable in 5.0
(b) Approvals which allow better control over sales and purchasing, and
(c) Export to Excel and Word using style sheets.

You'll have to wait for more details. I'll post them over the next few days.

Also, Microsoft Quarterly Partner Briefing for my area is next Wednesday. Might be something of note at that meeting.

NAV 5.0 NA (North American) database is now out...actually, the second release is out. I thought I'd try installing the client and the database. I loaded up a virtual machine copy that I've got with Windows XP and a couple of other things (like a SQL client) to serve as the base machine. Here's what I found in the installation.

• Microsoft.NET Framework 2.0 is required for the install.
• Looks like the install routine isn't quite ready for prime time yet. I got boxes for the license agreement for the .NET Framework. I was glad to agree to the boxes. Not sure exactly what I signed off on. It appeared that the document was created with a font I didn't have.
• While this was going on, I decided to install Office 2007 on my main machine (the one running the virtual machine).
• We finally have the new Dynamics "Wave" logo...looks kinda like the opera house in Sydney, Austrailia photographed from the right angle. With the possible exception of the fact that Sydney probably paid less for the opera house than Microsoft did for the logo and the logo has more colors
• SQL Server Express, the replacement for MSDE, is also (optionally, says the installer) installed for use with Nav 5.0. Rumor has it that 5.1 will require SQL...actually, at this point I'd say it was more than a rumor.
• The install of Office 2007 bombed out with a nonsense error. Think I had too many things going on at one time for it. No multitasking here...
• Installation of the C/Side client starts...and gives the standard options for "minimal," "complete," and "custom" installation. I choose complete, as usual.
• Installation complete. 5.0 runs.

Now we're cookin' with hot grease...I'll copy the NA database and our license and let you know later.

Project Green from Microsoft is dying. When Microsoft bought four ERP software packages, now named Microsoft Dynamics NAV, AX, SL, and GP, the company announced that their strategy was to merge all of these into a single product. Many of us groaned. Not only were the products--for the most part--strong in different markets, they were very different in construction and there were some functionality differences. Great Plains (GP), for example, uses third party software for warehouse functionality. Navision (NAV) has built in warehousing. SL (formerly known as Solomon) is strong in professional services; the other products--for the most part--aren't. In many cases the place in the software where functions are done is different.

To put it mildly, converging the products was going to be a nightmare for programmers, and a trial for users. But now Microsoft seems to be putting the project on hold. There's a redo of the interfaces for all the programs coming later this year, but here's what Microsoft's head of AX and NAV told eWeek:

"What we went out and said two years ago is that we would go out and converge the product and that was the priority No. 1 for Dynamics. We don't see that as a priority any more," said Mogens Munkholm Elsberg, general manager for Microsoft NAV and AX. "We think that over time we will add technology to the products that will be similar—like the SharePoint integration, like Web services, like the UI…It doesn't make them one code base, but it does make them closer to one another."

Sounds like an attempt to blur the distinctions between the products. But don't let the look-alike interface fool you. These are very different products.

Project Green is Dead—for the Foreseeable Future, at Least

Interesting week for rumors. After the rumor circulated about Project Green withering, the new rumor is that SL (Solomon) and GP (Great Plains) are to be shelved. AccountingTechnology editor-in-chief Bob Scott reported both on his Consulting Insights newsletter.

I'm with Bob, though. I don't think it's likely that Microsoft will kill a cash cow anytime soon. MS is likely to take a position much like Sage. Milk the dying product until you can kill it with a feather. Kind of like ACCPAC Plus which, after years of threats, Sage finally killed off last year.

I've finally had time to load the beta, order the beta license from MS, and get the whole thing going in a virtual PC. One of the things I picked out of the "What's New" training was the fact that some address fields (customers, vendors, contacts) had been lengthened. It's in the General Ledger part of that training if you're trying to find it.

I checked out the Names (which aren't listed as having been lengthened) and found that they, too, were now 50 characters. That's a good thing. I modified our first version (think it was 3.1 or something like that), and am still getting an occasional error message when I try to do something. The messages usually have to do with trying to copy a text field of 50 characters (what I made the fields) to a field of 30 characters (the old length). Of course, there is the "where used" tool in the developer toolkit, but it doesn't find everything.

We also noticed that the NA (North American) beta doesn't have payroll. Payroll 5.0 from Serenic should be out soon and includes a number of things like a wizard for adding employees. I figure the omission is just because it's a beta.

I got it in the mail today: Sage ACCPAC 5.4 Project and Job Cost.

Long history behind this product. Long and spotty.

Here goes. ACCPAC Plus (DOS) had a Job Cost product. It was simple. In the mid-80s it was pretty good compared to Peachtree (which was also a leading software product for what has now become the mid-market). The problem was that by the time ACCPAC was ready to move to Windows, it was still pretty much the same as it had been all along. It still didnt' support retainage very well. Still didn't have a great interface to Job Cost. And some other missing pieces. Things like Job Power or Timberline shamed it.

So ACCPAC decided (and announced) that there would NEVER be a Job Cost for Windows product. Network MicroSystems out of Austrailia decided this was an opportunity, and wrote the Job Cost for Windows package. It was basically a copy of the DOS package, and worked well for clients that liked the DOS product. (The web address for Network MicroSystems was nms.com.au, but all I get when I go there is a "Fedora Core Test Page" for Apache Server). So I guess they aren't around any more.

About 5 or 6 years ago, ACCPAC announced that they had changed their mind. They WOULD in fact be making a Job Cost product. And so they released it. No retainage in the first version. Lacking a number of features and a bit clunky in the second. The third major revision is now out.

I'm looking forward to digging in. Hope they fixed all of my pet peeves.

I've been revising the web site, slowly. There are more pages there than I realized, and updating them takes time. One page that's been sorely in need of revision is the Top 10 Accounting and ERP Packages page. Take a look.

Actually, I did more than I intended to do. I downloaded new copies of the PDFs for the software packages and put links to the web sites that were needed.

Hope you can make some use of the information on this page. My next job is to put up commentary about the software packages, and review all the information that's available on them. Meanwhile, if you're in the market for new ERP software, I've started a series on ceoTechCast (my podcast) about needs analysis and how it relates to selecting software. The first two segments are up.

Microsoft released Dynamics NAV 5.0 right on schedule on 3/31/07. It's now available for Partner Download, but most installations won't be upgrading anytime soon.

The current timetable shows the release version available for download now, the final CD shipping on 4/13, and the upgrade toolkit (required for upgrading any existing installations) within a month. I took a look on the upgrade toolkit site, and 2.00 for 4.0 SP3 is the last version showing on the list of downloadable toolkits at this point.

Some nice new features. We will convert our own database first, then begin scheduling client upgrades. My guess is that it will be the first of May to mid-May before the first upgrades to 5.0 are feasible. New installations will get 5.0 immediately.

I've been reading the list of the NAV 5.0 improvements. There are a few things that I'd noticed, but didn't know exactly why they were this way. Actually, I thought I might just be seeing things (or a bit touched in the head as some around the South used to say). Here is the list of interesting things for today:

• Zip code lookup now populates City AND State. Used to be that you entered the Zip code, and the city was populated...only the city. Couldn't figure that one out. Why? Guess what? It wasn't me. Now it populates both
• New check layouts. In previous versions, check below stubs was it for check format. Forget the 7 inch dot matrix forms. Now there are reports for the two stub checks (stub, stub, check AND stub, check, stub) as well as a long stub followed by a check. Brilliant!
• Logos on sales documents. This one was really a puzzler. Right there on the sales and receivables setup screen (see image) was an item asking where you wanted to put the logo that you could import into the Company Master. But it didn't appear where you said you wanted it. Guess what? Wasn't on the reports. Now is. Good thinking!

Most of the other stuff deserves its own post.

A little history is in order here. When Navision (now Microsoft Dynamics NAV) came to the US around 1990, it was primarily an European product, developed in Denmark. The international features of the product are rumored to be what Microsoft was interested in. But no matter...this post is about payroll...

Anyway, if anything differs from country to country, it is payroll. Different taxes, tax calculations, union requirements (or not), federal health insurance (or not), etc. So Navision made the decision (and a good one, thinks I), not to build a payroll program in the US, but to outsource it. They chose a company named VisionPay. The NAV payroll product was written by VisionPay, but included in the Microsoft distribution of the NAV product (at least the basic payroll and HR product was included in the Microsoft Dynamics NAV distribution.

VisionPay then merged with Serenic software, makers of another major add-in for NAV, and both took the name Sereinc Software...sounds nice and peaceful...

I've never been entirely sure what the contract between Microsoft and Serenic, but we always ordered the PR software from Microsoft and any additional (advanced) software from Serenic. Certification on the product was through Serenic, support was through Serenic, but the product came from Microsoft.

All that has changed now. The Serenic product will still be integrated into the NAV product, it will just be ordered from another source (direct from Serenic). This makes PR like any other product.

Confusing, I know. The rationale behind this seems to be to allow Serenic to better control the product. And from what we've seen of 5.0, this release will have some nice features. For example, an "add a new employee" wizard, and support for additional types of accruals and deductions as well as some really nice user interface work.

But...it won't be out until June 2007, at least that's the target date. Clients using payroll will have to wait until then.

As of tonight, the upgrade toolkit (required for migration of existing clients to 5.0) has not yet been released. We're still looking. Actually, according to the statement released by Microsoft, it should be out within the week. They initially said "within 30 days" of the release data which was 3/31/07. That would be about 4/29/07, or Sunday of this week.

I think I may have mentioned this, but the official word came down from Redmond (or Fargo, or wherever the source of power is these days) that Microsoft Dynamics NAV 5.1 (the big rewrite that will include the roles based interface and some other cool revisions) isn't coming out until 1st Quarter 2008 (I would add "at least.")

I expect to see this in 2008, but if it's the first quarter, I think it will be end of first quarter. The "technical preview" that was to be available with 5.0 was delayed and separated from that release. As of the last time about 10 days ago that I looked on the Microsoft site, it still wasn't there.

No big deal here. I think the delay is probably a good thing. More time to make sure the code is right.

Sorry, but I misread the announcement about the Dynamics NAV 5.1 delay. Microsoft uses these lovely little abbreviations. Q1 FY07 (first quarter, fiscal year 07, which begins at 7/1/07 since MS's year end is 6/30.) In this case, the new release date is H1 CY08. Translated into realspeak, that reads "The first half of 2008."

As much as I hate the expression, "My bad."

Still not out, as of today.

I feel bad about not posting much lately. I'll be out of pocket for the next few days...

Have a good Memorial Day!

Microsoft is being pretty quiet about when the NAV upgrade toolkit might be ready. We've heard, though, from one of the other related vendors that the current release is anticipated sometime in July...I expect that after we allow time to look at it and do a sample migration of our own data that we're looking at 4th Quarter before we start client migrations to 5.0 in earnest. We'll keep you updated, though.

Did you ever think about the process of implementing ERP software or accounting software? From the implementer's point of view, I mean.

When I was in public accounting, clients brought their tax records to us. Hopefully, they didn't bring the garbage bag or the box of checks; it was always better when they brought the tax organizer (key word: organizer). With a moderately complex organizer and the tax prep software we had, I could turn out a tax return in record time. Then I could reconcile the income to what was on the organizer, package it all up, and have it ready for review. Total time depended on the complexity of the return and the organization of the information, but it was pretty easy after a while to estimate the amount of time required.

Same thing for changing the oil in my car. And painting the outside of a house.

Enter ERP software.

No business worth its salt would buy ERP software and training without some estimate of the amount of time required to do it. Occasionally, I talk to businesses that have a quote for software and training. How much is the software, I ask. Big number follows. How much is the training? A small number (a few thousand dollars) follows.

"They quoted you two weeks of training, didn't they?" I ask.

"Yeah, how did you know?"

"Well, it's one of the lies ERP vendors tell."

See, ERP software is generally pretty complex. To make it more complex, it's not possible to grab the software (like grabbing a tax organizer), fill in all the blanks (like the tax software), and produce a finished product. Instead, you have to teach someone to use the software. And you have to help them mold their job to the software. Sometimes the people you're teaching have learned how to do it by rote. In that case, you have to teach them to do their job at the same time you teach them to use the software.

That isn't even to mention the fact that people generally don't like to practice with software ("Just crank it up and let me jump in.") Businesses don't seem to realize that the more distance they put between the original conversations about the system and the actual system implementation, the more likely things are to change. I've never had a business owner yet tell me, "Yeah, I know, I have really stupid employees...it's going to take you longer to train them than the normal business." Nope. Every business owner tells me, "We really have good people here, your job should be a breeze."

Guess what? An ERP company has control over only three variables: (a) the process they follow, (b) the estimate they choose to make for the cost of implementation and training, and (c) the people they send to do the training.

All the other hundreds of variables are in the hands of the organization implementing the software. It's hard to estimate a project that is controlled by someone else, and hard to keep it on track as well.

Leave some comments. I'd like your feedback. How would YOU fix this?

Software support fees have been sticking points with clients for years. Sometimes the value of support fees is difficult to see. Software vendors charge from a low of about 15% to a high of 25% per year for "maintenance" and "support." Depending on what is included in "support," this may be a good deal in the beginning. The definition of support ranges from "software upgrades and bug fixes only" (on the low end) to "telephone support" and sometimes "electronic support." Electronic support uses a tool to allow the support personnel to connect to and resolve issues with the customer's system. Telephone support is usually limited to suggestions for operating the software, not problem resolution. It can be difficult to diagnose software problems via telephone. This difficulty translates into cost for both the customer whose resources are tied up and the support provider.

SAP and Oracle are fighting about who gets to support old applications. In the SAP market, where products are typically highly customized and migrating to the next version can be very expensive, many clients stay on their old versions. This means that the longer the client is on the version, the lower the cost of providing service. SAP and Oracle haven't reduced prices, though. Now third party companies that have expertise in Oracle and SAP are offering these services. Take a look at the article from eWeek to see if this issue may relate to your situation.

Oracle's Suit Against SAP Raises Customer Concerns

I just saw this blog post. Don't know how I missed it. I've been fussing for years about the companies that implement (or don't implement) ERP. The issue that's raised here is important: ERP systems in some installations fail, and fail miserably. In others, they produce productivity increases. The initial difference in many cases is the implementation methodology, but also the willingness of the business to absorb the change in business processes required to get the most benefit from the software.

The blog post points out that IT expenditure is going up. That ERP system go-live seems to be linked to improvements in operational measures (e.g. turnover, employee productivity, etc.), but not to increased corporate income or better financial results.

I think this results from the fact that ERP systems are generally designed to ennable more work and more accurate work with the same employees. Take a look at the full article below.

ｻ The ERP mess we窶决e in | Irregular Enterprise | ZDNet.com

I was in line to get a hamburger at a fast food restaurant. When what should I see in front of me but a couple of legs sticking up from the side of a truck bed in front of me. Well, I grabbed my trusty digital camera and shot this picture.

Yesterday afternoon, I got the newest and best issue of the newsletter from Microsoft. And right there was what I'd predicted all along: NAV 5.1 (now we're going to call it 6.0 like we should have been doing all along) will be released (projected) Q4 CY2008. If you're not a Msoftie, that stands for 4th Quarter, Calendar Year 2008 (as opposed to 4th Quarter, Fiscal Year 2008 which would be 2Q CY2009 or something like that).

Anyway, the "preview" for partners will be out H1 CY2008 (yep, that's the first half of 2008), and we're just sure it'll be out promptly.

Now that I've allowed my snide and cynical side to write a few lines, let me tell you what I think this means from a business perspective.

One of the reasons we at DGG selected this product as one we would support was its design. Bluntly put, Navision (the Danish company) did a heck of a job developing not only the features and functions that are built into Dynamics NAV, but developing the tools that were used to build it. These tools are the same ones that clients and implementers use to do development work, and they're really top-notch for the type of work that is needed in an accounting system.

Anyway, NAV has been integrated into more of the Microsoft stack than most of the other products (it has--over the years--worked with BizTalk, Forcasting, FRx, Commerce Server, SQL, etc.) Many of these things were in place 3-4 years ago, long before other Microsoft ERP products integrated with these traditional products.

Also, NAV has far and away the largest feature set of any product in the Microsoft cradle. When we use our software evaluation database (that contains 150 or so products) to do needs analysis, NAV is often one of the last products left outside the Tier I space (that is, SAP, J D. Edwards, Oracle, etc.).

So I think it's pretty reasonable that it's taking Microsoft a while to make sure they're getting it right. Also, the last few demos I've seen of this new technology, Microsoft seems to be getting closer and closer to keeping the product easy to modify, install, and use.

I'm expecting to blog a lot more at the beginning of November from Directions 2007, the Dynamics NAV conference. Hopefully, we'll be able to tell you a lot more.

So if you think you see something dead in the back of Microsoft's truck...it's not a bad thing. Just think of it as a raccoon-skin hat. Oh, boy, that'll bring down the tree huggers.

Every email I've gotten from or about Sage recently, I've been looking for a major announcement of some kind. The announcement earlier in the year that the company had pushed the management groups for all the mid-market software products (Sage BusinessWorks, BusinessVision, ACCPAC, MAS90/200/500, Platinum, Pro Series, etc.) into one business unit was what I thought to be the beginning of the end for some of the products. This move looks to me like a profitability enhancing move. Which products will survive and which won't? Interestingly enough, Sage has also tightened the rules for business partners. It'll cost a bit more (travel, education, training) to be a business partner. Also, they established minimum sales in terms of dollars and units TO REMAIN A PARTNER. Traditionally, they've had other programs into which partners that were servicing the products but not selling them could move. Looks to me like these are being discouraged, and Sage is interested in retaining only the partners that are producing big sales and new sales.

I still think that if you're in one of the primary lines (MAS or ACCPAC), you're pretty safe. I'd be cautious with the other mid-market products from Sage. Also, there's a rumor that Sage is on the auction block again.

All of this interesting, don't you think?

Sage Software Cleans House

It's amazing how long it has been since I've written even a simple blog entry...but here's the thing: I've decided that there are an amazing number of bloggers out there that do a bang-up job of reporting on and commenting on the tech world.

My expertise is in business software (ERP, Accounting, etc.), software development, and business strategy.

So from now on, the comments here (as much as I can control myself) will be centered around those topics.

Please disagree. Please comment. I like to argue.

When Dynamics NAV 5.0 came out, one of the revisions to the product that I liked the most was the Outlook Sync revision. In the previous version, the Sync was real time, but I had problems with it. It duplicated data in both Contacts and Appointments, and I always wanted to be able to extract data from NAV into Outlook.

5.0 offered me this ability. There's a new release of the sync product. It's basically a re-do of some key areas. Take a look at the MS blog entry and tell us what you think.

MSDN Blog Postings ｻ Outlook Integration Update for Microsoft Dynamics NAV 5.0

It seems that all software vendors have an annual conference. Sage's Insights conference focuses on the Sage ACCPAC ERP product line. Sage ACCPAC ERP is--well, obviously--an ERP (Enterprise Resource Planning) software product. I'm increasingly reading various information that seems to imply that Sage partners are having trouble adding new customers at the rate they have in the past. His March 7 issue included the comment (talking about a new bundle that Sage had announced), "Given that, about two weeks ago, one reseller said new Sage sales are had to come by, this is worth a shot." Check out Bob Scott over at the Consulting Insights newsletter for his take on the issue.

Anyway, all that is to say that I've got my reservation for Insights and we'll see what's new at the conference. Looks like Bob Scott may even be there (along with the bevy of motivational speakers). It's May 12-15. I'll let you know what (if anything) looks new.

ERP software is just software. I do know that. However, the process of getting a group of people called a business (particularly a small business) using an ERP solution effectively is not trivial in the least.

I'm using the word "trivial" here as it might be applied in mathematics. For example, the solution to the equation 2x = 10 for x in base 10 number system is trival. x=5.

When I started out in public accounting, the central issue was training people to use the computer. "This is the on button..." type of training was almost inevitable. Today, the training we do has moved up the scale. We rarely have to tell a client how to use a data entry screen. The Accounts Payable Clerk takes one look at the invoice entry screen (for most any software) and says, "Ok, I see how it works."

The issues today have more to do with processes, personalities, and detailed functionality.

Managing the interactions between these three items makes the implementation process non-trivial. It's more like the solution to a complex differential equation.

Here are some general notes, with more details to follow in installments:

• Communicate with employees. Give them a reason to undergo the pain.


• Remember that big companies may work differently than small and mid-sized companies. In big companies, orders often come from on high, and must be accepted. This doesn't mean that employees don't complain. They do. It simply means that part of the environment at a big company is accepting decisions from the higher-ups that seem inane without saying much. In most smaller companies, we find much higher and more emotional feelings of buy-in from employees. This means that they'll react badly--and in extreme cases, try to sabatoge the project--if you don't deal well with them.


• Respect employee networks. Employees who have worked at businesses for a long time have relationships that aren't always apparent. These will come into play in stress


• Selecting the right software is only part of the battle. Every software selection is a tradeoff. No software has all the features. Be clear about what you're sacrificing.


• Watch for employee ownership of existing systems. In this case I mean BOTH computer systems AND business systems. Tell the sales force they'll be entering all their own orders in a company where this has never been the practice and you'll quickly see what I mean.

Enough for now. More to come.

I'm at the Sage Insights conference this week. As we mention on the web site, Sage owns millions of products.

Ok, well maybe not millions. But at least it's safe to say that Sage owns a bunch of products. For several years, as Sage acquired first one product and then the next, I've maintained that eventually they would have to give something up, or deemphasize some products in favor of others.

Of course the problem with that is that Sage has hundreds (maybe thousands) of business partners. (Several hundred of which are here at the Gaylord National this week.) And each of those business partners supports at least one, some more than one, but none all of the products Sage now owns. So no matter which products Sage picks to discontinue or deemphasize or disown, someone gets hacked off. In brief, there is someone out there who is feeding their family based on the Sage product that gets hacked.

So Sage has announced the creation of the "Strategic" products group and the "Value" products group. No surprise there...yet. And before I go on, let me say that Sage Accpac ERP (apparently Accpac is now spelled with upper and lower case letters after years of telling us that it should be all caps--Oh, wait, that was when another company owned it--never mind) is in the Strategic division. As are the MAS products (90/200 & 500). Note: 90 and 200 are the same basic code-base, only the database is different; 500 is a completely different product.

The surprises? Well, first Peachtree is in the Strategic division!! Not sure what that means, but it does mean that I need to take a look at Peachtree. The last time I did, I had a one word reaction: No!!

Other surprises: PFW (Platinum for Windows -- the traveling product, even IBM owned it at one time) is in Value; and Sage Pro (the former SBT) is in Value.

Would I worry if I had a value product? Probably not. TimeSlips (a perennial best-seller) is in Value, as are several other products that are important assets for Sage.

Too long an entry already. More later.

Although it had been announced before the conference, version 5.5 of the Sage ACCPAC ERP product is beginning to ship as of the end of April. We've released the first installment which includes the core product, but there appear to be several parts that aren't yet out.

The real news in this release is that Sage is giving users that are current on support agreements access to a number of products they would have had to pay for in the past. For example, serial and lot numbering has always been extra. Now it's included in the Inventory product. The "number change" utilities that allow users to change G/L account numbers, customer numbers, etc. have been bundled.

Most interesting, ACCPAC is including Alerts (not on the disks we've received to date) Lite and CRM in the core products. If you have System Manager, you'll get one user of the server, and 5 pre-built (non changeable) alerts.

Not a bad deal, but to my eye, an alternative to putting significant development dollars into the core product.

Customers with add-ons or third party products will have to wait a few weeks (maybe months) for compatibility with 5.5. Stay tuned for more.

I've been thinking a good bit lately about the information value of the reporting that comes from ERP systems. Most of the ERP systems in the market now focus on operating data. An example of reports available in most systems will clarify what I mean: accounts receivable aging (how much do people owe me? how long have they owed it?), inventory status report (how much of what do I have? where is it?), reorder status report (how much do I need to order?), etc.

Now suppose that I want to ask the question, "How healthy is this business?" "What kind of a year am I having?" "What will sales look like next month?"

Where would I go to get that data in the average ERP system?

Well, for some of the sales data, I could go to the pipeline reporting in a CRM system. Your ERP does have CRM, right? But if I really wanted a clear and accurate answer, I might have trouble getting it from the CRM pipeline report. There's nothing in that report (unless I built it into the process) to guarantee that the data I get is accurate. Furthermore, it is estimated. The estimate is based on an assessment of customer psychology by sales people whose jobs depend on their continuing ability to close sales. We might suspect that it is just a bit ambitious.

And none of this gives me an answer to the question, "How healthy..."

But the question most of the managers I know want to ask doesn't start with the six honest serving men (Kipling):

I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.

The question most managers I know want to ask starts with the word, "If..."

And where shall we find the answer to that question? In the next post? Doubt it. But maybe.

Well, Service Pack 1 is out...or is it. We've recently discovered that the NA localization isn't fully complete, and that there are several features that don't work that will be fixed.

For example, in the out of the box 5.0 release, POs don't work with Jobs. If you show the column for Job number in the details on the PO form (it's still there), enter a PO, and then receive (first) and invoice (second) the PO, you'll find that the cost has been posted to Usage twice in Jobs.

This will (reportedly) be fixed in SP 1, but that fix isn't out yet.

For now, be aware that if you have Jobs in Nav 4 with POs directed to them and you are using Receive separate from ship, you won't have this option in NAV 5. In fact, out of the box, you won't be able to enter a job number on a PO at all. Microsoft recommends receiving the item to inventory and then applying it in a job journal to a job (2 steps == stinky solution).

What does work is to go directly to the Purchase Invoices screen and enter it there (thus removing the opportunity to do a "receive.")

This is all related to the fact that costs posted to jobs in 4.x were at "expected" cost (i.e. basically at average cost or standard cost [if you were using standard]). When you ran Adjust Cost/Item entries, the FINANCIAL entries were made (e.g. DR inventory, CR COGS), but the JOB entries stayed the same. I did some testing and found out that the tracks were there to create a report that included the final adjustments, but it's pretty complicated.

Anyway, that's the situation. We're still waiting for a final Service Pack 1 upgrade.

Several years in the making, the role tailored client that is part of NAV 2009 appears ready to begin production. The VPC, What's New document, and several other pieces of the new product were made available to partners over the last week or so. We're delving into the product now.

Lots new under the hood.

As promised, though, all the functionality was released in the 5.0 SP1 version.

I just spent 3 days in training at Lanham Associates on their Dynamics NAV add-on product, ADCS (Automated Data Capture System). It's the wireless warehousing add-on that they developed to sit on top of the Dynamics NAV product. They wireless product in base NAV is functional at collecting the data, but it gives the warehouse employees relatively little in the way of ability to initiate transactions.

I must say, I'm impressed with the ADCS product. It does the things that you'd expect a warehouse system to do (pick, put-away, etc.), as well as allowing dynamic stuff in the warehouse (move this pallet over there, etc.)

Warehousing is one place that companies can really generate some ROI by improving processes, and my read on this product is that it can be very helpful in that regard. Post comments if you want more info on it. I'll post additional notes as I think of things to write.

I'm tempted to turn this into a general rant about resistance to change. I'll try to talk about NAV 2009, though.

Here's the brief 30,000 foot overview. As Microsoft promised, NAV 2009 contains no new functionality. All of that was released earlier in the year in Service Pack 1 to NAV 5.0.

The "What's New in NAV 2009" that has been released to partners is entirely about the new plumbing for the "Role Based" interface, as well as the changes that will affect the "Classic" interface.

So what do these interfaces look like?

The "Classic" interface is...well...the "classic" interface. It looks pretty much like NAV 5.0/5.0 SP 1 (View image).

The "Role Based" interface is wholly new. And I won't show it to you in this post. Why? Because I want to talk about the concept in this post, then show it in the next. See, I'm working through your resistance to the change here in this blog. Because I know that there's going to be resistance to change here. There are some things I really like about this interface; there are some things I really hate abou this interface. But whether I like or hate the changes to this interface, I'm comparing it to the "Classic" interface, and that's what existing users will do: compare it!

Let me say first that the NAV 2009 release offers the OPTION to use EITHER the classic OR the role based interface. Different people in the same company can use different interfaces. The controller may prefer the classic, while service people may prefer the role based. I did pick those two particular functions for a reason!

Here are a few of the new features I really like.

More User Control
=============

It's easier to customize screens like the Order Entry screen in NAV 2009. The basic order entry information (who's buying and what are they buying) is the same. It's the extra data that you might want (as a sidebar) that you can easily change. In the classic interface, there are links down the right-hand side of the OE screen. In the role based version, you can select which "fact boxes" appear, and what order they appear in. For example, you can display customer statistics, details, notes, and links on the list of sales orders. Once you select an order, there is (in the preview version) a list of 11 factboxes you can select from. Much of this information is the same information available in the 5.x version, but it's now customizable.

You can also control default sort order on many of the screens.

Office 2007 Menus
=============

NAV 2009 also introduces the "ribbon" concept which allows for display of common commands and reports across the top of the screen. Best yet, these are also user customizable.

Reporting Using SRS
===============

The one complaint I've had for several years is the formatting capability for reports and forms inside NAV. NAV 2009 creates data from within the same classic report designer, then pushes the data to the SQL Reporting Services (SRS) client for presentation. This gives the developer many more tools to use in formatting and making the data pretty. Not a big deal, perhaps, but eventually significant.

Home Pages
=========

Role-based home pages are a big improvement. The 2009 role center for Order Processing contains a summary of sales orders in the system. Under the heading of "Orders released not shipped" there are icons with counts of orders ready to ship, orders delayed, and partially shipped orders. Useful information to have for an order processing employee.

That's enough for a first post. In the next post, I'll show you the preview with a few more comments.

The preview of Dynamics NAV 2009 we can show to the public is finally out. The version I've been testing to now has been the Partner Technical Preview. It had a few features that I wasn't able to make work, so I'm interested to see if the new version resolves those problems.

I've been looking for the installation version (what we have so far is a Virtual PC with the software preinstalled). The installation for NAV 2009 is supposed to be a thing of beauty.

For those worried about changes, let me reiterate: there are no new features since 5.0 Service Pack 1, and the new interface (role based) is optional...but I think ultimately that many people will choose the role based interface over the classic client.

As soon as we've unwrapped the Virtual PC, I plan to post a few screen shots, some commentary, and a few comparisons to the classic client.

Also, it'll soon be time to think about re-recording our video training. I probably need to post a quick entry later in the week to describe what we're doing with the new training.

Click on the link below to see a screen shot of the NAV 2009 Role Center.

View image

This new interface sits inside a browser-like container. It's not quite a browser, but it has a lot of similar characteristics. For example, the back and forward buttons you see.

The idea of the role center is that the user interface that an Order Processor needs (the one in the screen shot is for this role) is different from the UI that a Warehouse Operator needs. One of the things that this interface does quite well is put operating information (like the number of released orders, partially shipped orders, and delayed orders) immediately in front of the operator.

This information has always been available (filter the Order screen, or print an order status report), but the grouping of the information as show on the Role Center makes it much more accessible. AND....clicking on the icon opens a list of the orders in that particular status. Nice touch!

All of this can be customized, and the underlying technology is not rocket science for an experienced programmer. Best of all, these are created in the traditional Dynamics NAV development tool (C/SIDE), so changing and updating the screens is pretty straightforward.

Interestingly enough, this interface is also user-customizeable. Note, for example, that the current settings have status information at the top and a summary of outlook at the bottom. This can be changed. In fact, parts can be removed or added. By clicking the customization button in the upper right hand corner (see below), and selecting the appropriate menu item, you get a customization interface.

View image

The customization interface looks like the screen shot below.

View image

If you think this looks something like SharePoint, you're right. I suspect that eventually this will migrate into SharePoint web parts. They look suspiciously similar as they are. And that's not a bad thing!

This week is Directions 2008, a conference put on by the Microsoft Dynamics NAV channel. Actually, a group of volunteers from a dozen or so Microsoft partners collect the money and host the event, which is limited to Microsoft NAV Partners only.

First thing this morning, we took a look at the integration between MOSS (Microsoft Office Sharepoint Services), InfoPath (a form design language), and NAV. The general plan was this: A user without a full NAV license, and without the permission to add a customer into NAV needed to request that a customer be created (think outside sales force). The user fills in an InfoPath form published on a MOSS server (which means that the user doesn't need any software other than a browser). The MOSS server is set up to go through an approval process (using SharePoint Workflow), and when approved, the customer winds up in NAV. Very sharp!

This also allows for workflow on the SharePoint site, which might be very helpful in an organization of any size.

Of course, I can think of a lot of ways to use this kind of functionality:

• Payroll benefits
• Vacation requests and records
• inventory items
• prospect credit approval (converting to customer)
• vendor approval

And since the processing in NAV was done by dumping the data into a temporary table, then reading the table with a codeunit (if you're not a NAV techie, read it this way: "Since the processing of the data collected was done INSIDE NAV"), the possibilities are literally endless for poking data into NAV where it needs to go.

Also, since MOSS licenses are MUCH cheaper than NAV client licenses, this is a potential cost saving measure as well.

More from Directions 2008 soon...

If you look at the "role center" for sales order processor, you'll notice a portion of the screen that shows data from Outlook. View image. You can actually click on the number of emails and launch Outlook.

For those of us familiar with SharePoint, this begs a question: Can we do this with other applications? Or can we develop our own "parts."

Turns out that the answer appears to be "Yes, but..." Yes, it WILL be possible, BUT it's not documented in the (first) 2009 release. We have to wait for that.

I'm not holding my breath.

Current word on the general availability date for NAV 2009 is 12/1/2008. After this date, the only new licenses that will be available from Microsoft will be NAV 2009. The version includes both the classic and the new role-tailored client, and the code base is theoretically identical to version 5, Service Pack 1. This applies--of course--only to the classic client.

Unmodified reports, forms, etc., will require no data conversion, modification, etc. (because you'll just use the NAV 2009 version of the code). Modified forms will need to be put through a conversion process to appear as "pages" in the new client.

Although the conversion tool can be run with minimal effort on an existing form, to make the new "page" really usable will take several steps. My guess is that future versions of NAV (perhaps a service pack?) will automate and combine these steps. They just seem too cumbersome to support the development process.

Some developers are already developing their own tools to handle some of the more time consuming steps. Eventually Microsoft will turn attention to this.

The good news is that the new client looks really good. In this release, I think most businesses will run both the classic and the new (role tailored) client.

You may not be using Microsoft Dynamics, but the author of this blog post about reporting errors is right on. While this is directed at developers, and at Microsoft Partners, knowing the "why" can help users make more efficient use of their support resources.

Read the full article.

IT Toolbox recently noted that 73% of all manufacturers are dissatisfied with their current ERP systems. Not surprising, they say.

The problem--says IT Toolbox--is the "legacy selection process commonly used is flawed." Bingo!

So what do they recommend? A three step process that begins with "define the critical requirements." Basically, a Needs Analysis!

Now where have I heard this before? Oh, right, that's the way DGG has done it for twenty years!

If you want the details on this process, check out the Guide To Selecting Business Software, available for free.

I just love it when someone else touts a "revolutionary" process that's as old as the hills. Why don't people do it this way? Because it takes more time. It's also more precise.

An ERP Selection Process that Guarantees Results!

Over the weekend, a friend of mine that teaches CPAs about technology, Brian Tankersley, emailed me about open source ERP. I've written about it, but not for a while. Thought I might post why.

I got down to two products. I got both of them installed (names removed to protect the guilty). Got them to work on both Windows and Linux; actually got them to work on several distributions of Linux.

Then I bought the manual for a few bucks because the UI wasn't really intuitive. By that I mean that I couldn't figure out from the online help and the sample data how to add a customer and an item and invoice the item to the customer. After I got the book, I got an invoice to come out. Then I started searching for a report that would show the debits and the credits (accountant stuff) that had been generated.

Then I looked some more.

And I read the book (see, Honey, I really do read the instructions!).

And I read the book some more.

And I printed some more reports.

I looked for all the good names I'd found for 25 years: transaction, transaction details, etc.

And then I gave up.

That was about 10 months ago.

Never found those transactions.

A post or so ago, I was talking about OpenSource ERP. Someone posted a comment that suggested I look at xTuple. So here's the look.

First of all, xTuple isn't GPL, it's CPAL. In fact, two editions of xTuple are proprietary license. Qualification: I am not and do not wish to be a lawyer. (No, I didn't read the fine print, I don't have time to read the fine print.) If you want a quick and dirty overview of CPAL, here's one. CPAL is a mod of the MPL license used by Mozilla for Firefox, though. IT IS NOT GPL compatible.

Second, if you need multiple warehouses, manufacturing, stock transfers between warehouses, serial or lot numbers, manufacturing (MRP) or a host of other things, you'll have to pay to get them. The pricing includes a couple of options: annual licensing (you pay every year per user to use the product), and a perpetual licensing with upgrades (like what all the top 10 packages have). The pricing for the perpetual license and the support is actually higher than what you woul pay for equivalent functionality with some of the more popular solutions.

Third, the CPAL edition includes only basic, one location inventory, order entry, some work orders, and some CRM. BOMs and kits are available.You can have multiple locations in the warehouse, but there is no detailed documentation to indicate whether this is what is usually called bins with put and pick functionality or if it's something much simpler.

I got to this point in the review and clicked on several links on the site to review detailed specs on the product versions of xTuple. I've been waiting long enough to have saved this post and gone to get breakfast (in the next room).

Sorry xTuple or OpenMFG (which was the previous name), I can't wait any longer. Might get back to you in a couple of days when the site works better.

Block does a good job of pointing out the advantages of QuickBooks vis-a-vis Peachtree here. If you are thinking of purchasing one or the other, you might want to consider his ideas.

He is correct that there are a large number of QB add-ons, and that the SDK provides an API (application programmer interface) that is very functional. I suspect however, that the number of downloads of the SDK indicates more that it is free and there is interest than that this many products will be built for QuickBooks. One should also know that some of the add-ons will not work together so if you need one, you're good. If you need two, be sure they are compatible.

The point that is omitted is that almost no one purchases QuickBooks because it has all the features they need. They purchase it because it is (a) very inexpensive (I almost wrote cheap), and (b) many bookkeepers and CPAs know it. These are very important considerations, and are part of the reason that Data Guidance Group supports the product.

However, with any software selection, it is important to understand the needs of the business before purchasing. There are some things that QuickBooks does not do or does not do well which indicate a need for other options. There are also things that SAP or J D Edwards does not do or does not do well. All of these need to be considered.

To put it succinctly, a partner in the CPA firm I worked for 20 years ago once asked me, "What is the best computer?"

My answer (still): "That all depends on what you are trying to do."

QuickBooks-Blog.com: QuickBooks vs. Peachtree, QuickBooks add-ons

Since I work a good bit in manufacturing and distribution, items are important. I've been looking at the video on items. There is a good bit of functionality here. The devil, though, is always in the details, and I highly recommend that any business looking for an ERP solution do a Needs Analysis (NOT A RFP) before moving forward. For more information on Needs Analysis, check out the Guide To Selecting Busness Software. And if you want to know why an RFP isn't my preferred method, listen to ceoTechCast #11 - 5 + 1 Reasons Not to do an RFP.

Here are a few of my questions after watching the items video:

• What costing methods are supported? Standard? Average? Weighted Average? LIFO? FIFO? Specific (since it supports serial #s)? It appears that average, standard, and something called Job are the only cost types available.


• How are Sales and COGS G/L Accounts controlled? It looks like the cost side of this is controlled through the Cost Category on the item. What happens if this is changed when there is inventory quantity and cost of the item on hand? The sales category looks to control the sales side of this.


• Why is there a need for a G/L Series Discrepancy Account? The description says that it is used for penny variances due to rounding. These simply shouldn't occur in G/L entries in a robust application. Here is the page describing the account: http://www.xtuple.org/sites/default/files/refguide/webdoc-3.2.0/ch10s13s08.html


• Is there a way to handle drop shipped items and special orders?


• Can you copy old orders or POs to make new orders or POs?

I'll stop there with the review. There seem to be a number of things in this product that should be carefully considered in a Needs Analysis.

Summary:
(Per the Creative Commons license, this must be reproduced IN ITS ENTIRETY.)
There is some good and some bad in this application. It has a good bit of functionality from an operational standpoint, but the things I found in a brief review that have been left out give me concern about whether it represents a broad enough application for use in an average business.

If price is a concern, QuickBooks Enterprise Solution (disclosure: my company works with this product), Peachtree (disclosure: we don't work with this), and an add-on manufacturing solution like MiSys (disclosure: my company works with this solution) will prove equal in functionality and probably less expensive than this solution.

User pricing for the two pay solutions is above charges for some of the major manufacturers.

I would consider this application only if (a) you have a commitment to open source and a programming background, (b) it has specific features you are looking for and does not lack for features you need, or (c) you have looked at other solutions and believe this one is better.

The title of the article below seems a bit misleading to me. It's not clear to me that there is evidence of SAP's unravelling, unless the reference is to SAP losing market share. Furthermore, I don't think at this point that this can be identified as a permanent trend, perhaps the market segments that SAP targets are more affected by the global recession than Oracle's market segments.

It is, however, encouraging to see one more voice added to the chorus of voices in support of a recovery.

Oracle Says Market's Recovering But SAP's Unraveling - Global CIO Blog - InformationWeek

C.H. Dodd once defined a (Biblical) parable as "a metaphor or simile drawn from nature or common life, arresting the hearer by its vividness or strangeness and leaving the mind in sufficient doubt about its application to tease it into active thought."

That's what this is. It's not about religion. It is a parable about ERP Software.

My neighbor is building an addition to his house. He called several builders, a general contractor or two, and finally his brother-in-law. He then (wisely) hired a general contractor with a good bit of gray in his hair to "help him build the addition."

The contractor showed up and asked my neighbor, "Where are the plans?"

My neighbor pointed to his temple and tapped it. The contractor rolled his eyes.

"Let's at least sketch out something on this graph paper," recommended the contractor. So my neighbor got out his pencil and began to sketch.

"You'll save some money if we design this like so, and move this unit over here," recommended the contractor.

"Naw," said my neighbor, "that would ruin the asthetics of the back yard."

"Ok," said the contractor, "I've got some men lined up to do the work. When do you want to start? I'll line up the concrete."

"I think you'd better show me how to use a hammer and a saw," answered my neighbor.

"Why?" asked the contractor.

"Because I'm going to help build this addition."

The next few days were spent with the contractor giving lessons on everything from 8, 10 and 16 penny nails to how to use a hand saw without getting "kick back." Several times, the contractor recommended ways to cut corners, and said that it might be cheaper just to allow his men to do the work. Each time, my neighbor had a reason that the contractor's suggestion wouldn't work. Each time, the contractor said quietly, "Ok."

Two weeks into the construction job, I heard my neighbor screaming in the back yard. I went out to see what was going on. He was looking at a piece of printed paper.

"We haven't even poured the slab yet, and this is your bill?" he asked the contractor.

"Yep," said the contractor simply.

"This is outrageous," said my neighbor. "This is way over budget!"

"Yep," said the contractor.

"How in the world can you be this far over budget and the construction isn't even finished yet?" asked my neighbor.

The contractor just looked at him.