THAT's the point

Miklos_Hollender · 2006-12-19

Finally! There is a study from a serious research firm proving the point some of us were always complaining about - that not only with Navision but with ERP software in general, usability is horrible from the end user's viewpoint and it requires loads of often unpaid hacking from a developer's viewpoint. They've investigated 11 ERP software and the results were abysmal.

http://news.zdnet.com/2100-3513_22-980648.html

Two thumbs up, Forrester Research! Finally somebody dares to point out that the emperor is naked.

Captain_DX4 · 2006-12-19

Without details of issues, it's hard to say how they are rating all these applications. While I believe that some packages are able to perform certain tasks better than others, I would tend to agree with the overall sentiment that ERP manufacturers can "pull up their socks" and develop more intuitive and user-friendly interfaces.

It seems that since Microsoft has taken over Navision, the trend has been more and more that fixes aren't made and PUBLISHED as their found. Remember when Navision would publish a hotfix or improvement that would only address bugs? Now it seems that anything that can, WILL wait until the next version release. Unfortunately it seems that each version released includes a host of new functionality that ends up being as buggy as predecessors in new and weird ways, thus never leaving the customer with a sense of satisfaction or a comfort level that the application is 100% stable. "Too much, too fast, Microsoft!"

themave · 2006-12-19

I couldn't agree more, as an end user myself, I find most of our changes to Navision are to make the screen easier for data entry, and the reports.
don't get me started on the reports.

You would think that if the item no field is 20 charactures long that who ever designed the built in reports would have known that. There is not a single report in Navision that will by defualt show the entire part number.

Not a single report, that is just stupid. Every single inventory report we use has to be modified, to print out the entire item number. and that is only the tip of the iceburg

Then every one of these reports, when we upgrade has to be redone again.

DenSter · 2006-12-19

themave wrote:

Then every one of these reports, when we upgrade has to be redone again.

Only if the person doing the upgrade doesn't know what they are doing. During the upgrade, if you know what to look for, it is possible to keep control dimensions intact.

You should make it a habit anyway not to use standard reports but to create your own. You can start with a copy of the standard reports of course, but that way you never have to worry about them being replaced during an upgrade.

themave · 2006-12-19

DenSter wrote:

themave wrote:

Then every one of these reports, when we upgrade has to be redone again.

Only if the person doing the upgrade doesn't know what they are doing. During the upgrade, if you know what to look for, it is possible to keep control dimensions intact.

You should make it a habit anyway not to use standard reports but to create your own. You can start with a copy of the standard reports of course, but that way you never have to worry about them being replaced during an upgrade.

Sure, but at a great cost, if I want the programer to upgrade the reports, their estimate to me is 15 - 30 minutes per modified object to determine the upgrade cost. that 15 - 30 minutes is not included in the upgrade it is the cost to give the upgrade estimate.

So, a good programmer can do it probably easily, but certainly not cheaply, And this is for a report that should have the field show without modification.

themave · 2006-12-19

DenSter wrote:

You should make it a habit anyway not to use standard reports but to create your own. You can start with a copy of the standard reports of course, but that way you never have to worry about them being replaced during an upgrade.

Again at a cost, we purchased the report writer which came with 100 reports, additional reports cost $800 per 100 units. So, Navision has a report that works nicely, except it doesn't print the whole field, so for Inventory, I would need to use probably 50 reports out of my 100 unit block

Yes, I know I can buy Crystel reports, or some other external program, but why should I have too. just to make upgrading easier. I guess I could leave Navision standard and use SAP instead, (just being sacrastic)

ara3n · 2006-12-19

I believe SQL reporting services, automatically increase the length of the field on report.
Since the designer will be done outside of navision, I don't know how long it will take to upgrade to 5.1 each report. :-k

Savatage · 2006-12-19

I always thought it was funny that when we first got Navision that our nsc had to change the picking ticking to print in shelf/bin order.

I figured that was a given.

Common sence...That's the point!

----
Yes almost every report we used had to be changed.
Mostly removing crap fields and enlarging the fonts from that miniscule 7 that these reports use

We're not spring chickens with eagle eyes anymore.
----

You should see how cool my AR aging is now

EDIT: I've found Arial Narrow to be a godsend!

Captain_DX4 · 2006-12-19

ara3n wrote:

I believe SQL reporting services, automatically increase the length of the field on report.
Since the designer will be done outside of navision, I don't know how long it will take to upgrade to 5.1 each report. :-k

I don't see how reporting services would do this, unless you mean for the upcoming version?

Captain_DX4 · 2006-12-19

Funny how we are talking about changing reports. Guess what I'm working on today? *lol*

The issue where the standard reports do not print out the full width of the field, I would completely agree. It should make sense for Navision to do this. On the other hand, the issues where companies make customizations to reports for their own business purposes (dropping fields, adding fields) I believe should be regarded as a necessary cost. The whole issue is that how can any company developing an ERP anticipate what 100% of the customers are going to want their reports to look like? That's not going to happen. *hehe*

It just occurred to me that it would be very cool if the development of the code for the report and the development of how it is displayed could be separate objects. That would make it much easier to make the cosmetic changes, but when an upgrade occurs and you want to make sure the guts of the report are working properly, 9 times out of 10 you will probably only need to update the code. Wouldn't that be a nice feature? *wink*

Miklos_Hollender · 2006-12-20

When I started working with NAV in 2002 first I just thought the core developers are just sloppy guys. Later on I've heard - and seen - so many horrors about iScala, SunSystems, SAP B1, Axapta etc. that I realized that it's the very ERP industry itself that's extremely sloppy and compared to the average the NAV core developers are kind of OK.

But what's the reason that this industry can get away with products that suffer from quality issues so serious that other kinds of software f.e. PhotoShop would not allow themselves?

The usual answer is "because ERP needs so many features" and "because everybody wants things differently". Well, at the end of an implementation project it's surely true. But I think it would be better both for customers and for implementors to have standard system that has a small set of features but those are working perfectly. In this case the project would concentrate on extending the system, with safely knowing that those features we already have we can trust. What we are having instead is a large number of features that always need to be heavily tested, bugfixed, worked around and usability-improved.I mean if I buy a car knowing it's slow but otherwise reliable, I'm willing to pay for a modification f.e. "chip tuning" to make it faster, no prob with that. But buying a fast car and visiting the service each month because something always breaks is much worse. The problem is I think that ERP vendors don't do direct sales just marketing, it's always the partners who sell. And in a marketing brochure a fast and unreliable car certainly looks better than a reliable, but slow one. Reliability - genuine quality - is always outside the scope of marketing brochures. I think this is the reason.

About a year before I had a secret plan of switching to SAP B1, because from afar it looked right: it looked something small, but good, which rather needs to be extended than customized. But after that I learned that even though it has about half the features of NAV and some nice things (alerts etc.) they somehow managed to make it even buggier and even more unreliable. I have no idea why or how as I swear that three smart young guys with a Delphi would write something like SAP B1 in 18 months and it would be reliable and fairly bugless. So it seems I stay with NAV.

Interestingly, Open Source alternatives are getting better. Compiere can gracefully merge two customers if you realize they are duplicates, with all the entries, orders and whatever. How many commercial ERP products we know that can do it?

I'm trying to find out the real reason why the ERP industry is so sloppy for years now. And the most realistic reason is a bit frightening: it seems that only about 10-20% of total development hours spent on ERP are put into developing products, add-ons, and customizations for clients. 80% is in-house development of the internal teams of bigger end-user companies - either starting from scratch or using some modules from a commercial ERP system and heavily customizing it themselves. This is the whole point of Java for example. All that fuss and ooh and aah about Java being "the" "enterprise platform" means thousands and thousands of companies having teams of internal developers build ERP-like business systems for internal use in Java. So the frightening truth might be that "the world" is being largely ran by internally developed systems and if you buy a software, if you buy customization, it's rather the exception than the rule. The decision to buy instead of build might mean about the same as the decision of buying a used car. That would explain a lot of things but I hope it isn't true.

DenSter · 2006-12-20

themave wrote:

Again at a cost, we purchased the report writer which came with 100 reports, additional reports cost $800 per 100 units.

I understand, everything is at a cost, and it adds up quickly, and it is very easy for me to say these general things. Consider though $800 for 100 completely safe (as in unaffected by any NAV upgrade) custom objects versus the cost of upgrading the standard ones. I just think that during the upgrade these fields should have been left the size that they were in your customized reports is what I am saying, assuming that widening the controls is all that was done to them.

By the way, I completely agree that a textbox for a 20 character field should be big enough to display all 20 characters. Just to play devil's advocate though, there are more fields on those reports. You try putting textboxes on report for all the fields that you want with the max number of upper case W's in there, and you see how many fields will fit on the report. There has to be a balance, and unfortunately the balance doesn't seem to work for anyone 100% of the time.

You want safe reports? Use custom ones. You don't want to pay for custom ones? Customize standard ones and run into upgrade problems. It's a little less cut and dry of course (do you want to use a custom report just for a wider number field, i.e. does this particular customization warrant the usage of a custom report object), but that's essentially the decision that you have to make.

DenSter · 2006-12-20

themave wrote:

And this is for a report that should have the field show without modification.

Every customer has a problem with one feature or another, whether it is the width of a control, or the way that prices are processed, or if the stockkeeping unit table should really be called that way, or any other 'feature'. Each one of them says that it should be included in the standard product. Standard NAV, like any other ERP product, is the culmination of the designer's idea of a set of best practices, whether you agree with that or not.

You will never find a system that will comply with everyone's notion of what the standard product should include, however frustrating that may be. I just happen to have stumbled into NAV at some point and think that it is a pretty good and solid product that can be modified to fit a customer's need fairly easily. Fortunately, there are many different companies that all have their own specific way of doing business. Unfortunately, they all THINK that the way that they do it is 'the industry standard'.

Please don't get me wrong, I do not intend to trivialize your issue, as I agree to a certain extent. Most implementations don't use all 20 characters, and if they do they don't need the controls to be 20 W's wide. So they made the controls a certain width as a compromise, to be able to fit other controls as well. It's unfortunate that you had to modify all the inventory reports, but I can also see why the compromise had to be made.

ara3n · 2006-12-20

Interestingly, Open Source alternatives are getting better. Compiere can gracefully merge two customers if you realize they are duplicates, with all the entries, orders and whatever. How many commercial ERP products we know that can do it?

Navision can do that. You can merge GL accounts, vendors, Items, almost any table in Navision can be merged.

Here is an example. on how to merge two customers. A, and B.

CustA.get(A);

CustA.Delete;

CustB.get(B);

CustB.rename(A);

You have make decision about dimensions or other table that have customer no as PK, but that's it. you can do this on items, vendors.

Phenno · 2006-12-20

ara3n wrote:

Interestingly, Open Source alternatives are getting better. Compiere can gracefully merge two customers if you realize they are duplicates, with all the entries, orders and whatever. How many commercial ERP products we know that can do it?

Navision can do that. You can merge GL accounts, vendors, Items, almost any table in Navision can be merged.

Here is an example. on how to merge two customers. A, and B.

CustA.get(A);

CustA.Delete;

CustB.get(B);

CustB.rename(A);

You have make decision about dimensions or other table that have customer no as PK, but that's it. you can do this on items, vendors.

Interesting... never thought about that.
Tips&Tricks?

David_Cox · 2006-12-20

themave wrote:

I couldn't agree more, as an end user myself, I find most of our changes to Navision are to make the screen easier for data entry, and the reports.
don't get me started on the reports.

You would think that if the item no field is 20 charactures long that who ever designed the built in reports would have known that. There is not a single report in Navision that will by defualt show the entire part number.

Not a single report, that is just stupid. Every single inventory report we use has to be modified, to print out the entire item number. and that is only the tip of the iceburg

Then every one of these reports, when we upgrade has to be redone again.

I bet there are more companies where the item number size is fine than not!
Some will say there are fields they do not need on the Reports, but is this not the same from any software aimed at a diverse market?
Navision has never been sold as a one size fits all, but as a 20% - 80% fit.

One option for upgrade is to export your reports, and re import them, unless there are new Navision fields you want, nine out of ten times this works with no extra requirement.

The cost of the upgrade becomes greater when you have a heavily modifed database, I will always look at the standard fields to see if they could be used, rather than add fields and keys, due to the impact on speed and cost of upgrade, changes of fields and code should only be added to standard tables as a last resort.
The investment in extra Tables,Reports and Codeunits, is better than costly upgrades, I use codeunits a lot during development, and pass standard records to my codeunits to carry out the Customers requirement.
Upgrading the standard objects, is then much easier, add new fields, then add in the codeunit variables and the calls to these, so instead of adding 40 lines of code and new functions to the sales line table, I simply add
Clear(MyCodeunit);
MyCodeunit.RUN(Rec);

Back on the Subject:
SAP :evil: are really trying to have a grab at the Middle market, as it has exhausted the top end, I am working from home today and just heard thier Advert on SKY Channel :shock: !

Miklos_Hollender · 2006-12-20

But looking at things from the other way around: why do you have to upgrade something if you finally managed to get it right? For keeping up with technology, technical upgrades (installing new clients) will do. Everything else is just application logic. If it suits you - stick to that, I think.

I think the major reason of upgrades that there tend to errors in application areas (costing, reservation, tracking, manufacturing planning... ) that have so complicated code that debugging them would be horribly expensive. In this case, keep in mind that you are probably just using a subset of the complexity these features require. And you might as well work around the feature and have a much simpler custom feature replacing that. F.e. if you keep having errors in reservation but basically all you need is reservations between sales and inventory and nothing else, then you can probably replace the reservation system with a custom one - still using the Reservation Entry table, for example, but having custom functions. Building a simple reservation system that only connects sales and inventory is about 2 days at most. Four, if you include the cost of some specification and testing. (Actually in a real emergency one could hack it up in two hours, but that wouldn't be very reliable.) And with such a replacement the need for an upgrade might go away. So I think an upgrade is like a divorce - do if there is a good reason to.

Of course in the long run so many features are added that an upgrade looks better and better. That's fine. Impementing 2.6 five years ago and now moving to 40 SP3 is logical I think. There are so many things added that it worths the cost. But I wouldn't go from 4.0 to 4.0 SP3 unless there is a good reason to.

ara3n · 2006-12-20

Phenno wrote:

ara3n wrote:

Interestingly, Open Source alternatives are getting better. Compiere can gracefully merge two customers if you realize they are duplicates, with all the entries, orders and whatever. How many commercial ERP products we know that can do it?

Navision can do that. You can merge GL accounts, vendors, Items, almost any table in Navision can be merged.

Here is an example. on how to merge two customers. A, and B.

CustA.get(A);

CustA.Delete;

CustB.get(B);

CustB.rename(A);

You have make decision about dimensions or other table that have customer no as PK, but that's it. you can do this on items, vendors.

Interesting... never thought about that.
Tips&Tricks?

I guess. I can put up there. I've done this for a couple of clients.

Miklos_Hollender · 2006-12-20

DenSter,

Fortunately, there are many different companies that all have their own specific way of doing business. Unfortunately, they all THINK that the way that they do it is 'the industry standard'.

I don't think it's really about doing business. There are loads and loads of things that everybody would expect. Just one example, ideally, all menu items, forms, fields everything should disappear you don't have the licence for using. I know in the current architecture it's impossible because the licence is basically something like an unchangeable User Permission so it works at object level. But this only means the current design is imperfect. In an ideal architecture each user interface element would have something like a granuleID property and would be showed based on it.

I mean you think that it's an ideal behaviour for a software that you have something on your screen, you happily click on it and it says no-no, my friend, you cannot? Gosh, all the basic principles of usability are based on ideas that if "the computer" knows that I cannot do that then it shouldn't even offer the option. The most basic principle of good usability is "the computer must not ask a question it can figure out itself". It's the way Windows or Mac OSX is designed. Look at any simple shareware utility, you can bet that the functions you can only used in the registered version are at least grayed out so you know you cannot use them without being annoyed by error messages.

It's the way mostly everything is designed - except for most ERP, CRM etc. packages.

It's not only Navision, it's mostly everything. It seems the industry is late about 10 years - ERP/CRM/SCM/whatever usability is roughly similar to Windows/Office in 1996.

Miklos_Hollender · 2006-12-20

I mean, there are discussions in the blogospere about Windows having options for restart/hibernate/sleep/shutdown/logoff/lock is bad for usability because it's hard to explain to your 70 years old uncle what's the difference exactly is. And that how cool the iPod is that it doesn't have an On/Off button so you have one less unnecessary options, which means less confusion and therefore more usability.

How amazingly far our industry is from it...

David_Cox · 2006-12-20

mean you think that it's an ideal behaviour for a software that you have something on your screen, you happily click on it and it says no-no, my friend, you cannot? Gosh, all the basic principles of usability are based on ideas that if "the computer" knows that I cannot do that then it shouldn't even offer the option.

I used to think the same all these menu's and you can't use half of them, make them invisible.

Then the MD said "If we hide these Menu's or Items our Customer might never know that these functions exist, they could in time as business needs change need these, and look for other software"
Also your Customer could be showing Navision to a visitor or a Manager from another business within the group, the visitor seeing the small menu choice thinks that Navision will not fit thier business needs, and you have just lost a prospect that already has a leaning towards Navision.

They soon get to know what they have the licence to do and stop exploring!

I just brought a Canon Camera, lots of options to learn, but for now Auto is fine, when I am ready to explore I will, some of this will mean spending more, monopod, tripod for long exposure, filters, zoom lens etc, but if the options were not there I would not be thinking of expanding my photograpy skills, and spending more on the product.

IMHO. Don't hide Menus or Items

themave · 2006-12-20

So, Sacrafice day to day usability as a sales pitch for the software vendor?

The solution center should know the products capabilities and when a customer needs something, say Navision has this function and it cost x dollars, or we can program it for you for x dollars.

Leave the customer with a cronus database and license that can access everything, and he can use that to see if Navision has something he might need that he currently doesn't license.

After all, just seeing a menu item that you can not test out doesn't tell you if it will meet your needs anyways, and it is a pain in the butt to field calls from users saying, "I selected "XYZ" and the system says I don't have permission, contact your administrator, which is me, can you add it for me ?

David_Cox · 2006-12-20

themave wrote:

So, Sacrafice day to day usability as a sales pitch for the software vendor?

The solution center should know the products capabilities and when a customer needs something, say Navision has this function and it cost x dollars, or we can program it for you for x dollars.

Leave the customer with a cronus database and license that can access everything, and he can use that to see if Navision has something he might need that he currently doesn't license.

After all, just seeing a menu item that you can not test out doesn't tell you if it will meet your needs anyways, and it is a pain in the butt to field calls from users saying, "I selected "XYZ" and the system says I don't have permission, contact your administrator, which is me, can you add it for me ?

Why did the user select "XYZ", is this something that will enhance the business, something we overlooked when we purchased Navision, something we have on another system that we are paying support for, something we should start to use, or is the user just being a turkey?

themave · 2006-12-20

David Cox wrote:

I bet there are more companies where the item number size is fine than not!
Some will say there are fields they do not need on the Reports, but is this not the same from any software aimed at a diverse market?
Navision has never been sold as a one size fits all, but as a 20% - 80% fit.

this is true, but there are also a lot of companies that need more then 20 spaces, I see the question on this forum all the time, I need to expand the item no. is there any problem doing that ?

My point is not so much about a single field in a single report. It is that a primary key field is likely to be an important field, and it would be logical to show the entire field in a report, since as a programer it has already been identified as the one field in the entire table that unique and the single most import field as all related information ties to it. Instead Navision routinly shows only 2/3's of the primary key in many different reports, besides just the Item reports.

It gets to what Miklos Hollender has been saying about usability.

themave · 2006-12-20

themave wrote:

.. Instead Navision routinly shows only 2/3's of the primary key in many different reports, besides just the Item reports.

It gets to what Miklos Hollender has been saying about usability.

Now before everyone focuses on the 2/3's number instead of the idea, I will concede it could be 3/4's or 5/8's or any other percentage you think it is (LOL)

DenSter · 2006-12-20

Miklos Hollender wrote:

There are loads and loads of things that everybody would expect.

See I simply disagree with you. Every customer is different, and every single one of them says the same thing ("that should be standard") about different things that are "wrong" in the application. In every single one of those cases, fro that particular customer's perspective I can see their point, because it is from their particular experience. At the same time that I agree with them that it would be nice to have the feature as a standard, I can also see why it is done a certain way in NAV.

David_Cox · 2006-12-20

this is true, but there are also a lot of companies that need more then 20 spaces, I see the question on this forum all the time, I need to expand the item no. is there any problem doing that ?

I am currently working on a solution sending Navision sales data to SAP R3, we have just been told that the Document Number can be Numeric or AlphaNumeric, but cannot be NumericAlphaNumeric, and can have Max 10 digits. 600001 and INV0001 are ok, But it cannot deal with 06-INV0001 how sad

.

themave · 2006-12-20

David Cox wrote:

Why did the user select "XYZ", is this something that will enhance the business, something we overlooked when we purchased Navision, something we have on another system that we are paying support for, something we should start to use, or is the user just being a turkey?

Nice, that is pretty good, the answer though is because new users press every item they can find to see what it does :roll: Or they just simple clicked the mouse too fast and hit the wrong item on a function menu, as the function menu on the sales order has 17 items that can be selected.

Yeah I know I can edit the menus so they don't all show up, but the early suggestion I got was to leave it standard to make upgrading easier.

so again it gets back to usability, do I modify it to make it more user friendly, and harder to upgrade, or do I leave it alone, and make the day to day work harder, to cut cost in the future upgrade.

I am not really asking that question because the answer is modify it for the day to day work, and hope that someday Miklos Hollender gets put in charge of usability at the Dynamic division. :P

Savatage · 2006-12-20

Miklos Hollender wrote:

But looking at things from the other way around: why do you have to upgrade something if you finally managed to get it right? For keeping up with technology, technical upgrades (installing new clients) will do. Everything else is just application logic. If it suits you - stick to that, I think.

Sounds like us

Don't fix what's not broke - That's the point!

DenSter · 2006-12-20

themave wrote:

<snip> it has already been identified as the one field in the entire table that unique and the single most import field as all related information ties to it. <snip>

The single purpose of a primary key is to be able to uniquely identify records in the table, it has nothing to do with the 'importance' of the field. With 20 characters you have (assuming that you are using only letters and numbers) 36 (A-Z plus 0-9) to the power of 20 unique values at your disposal, which is more than enough for any system. The only valid reason (IMHO of course

) why anyone would need more than 20 characters is when a customer is coming from a legacy system and they don't want to go through a renumbering during data migration.

You'd be much better off using specific fields for specific purposes, that's much easier to program, filter, report, etc.

themave · 2006-12-20

Savatage wrote:

Miklos Hollender wrote:

But looking at things from the other way around: why do you have to upgrade something if you finally managed to get it right? For keeping up with technology, technical upgrades (installing new clients) will do. Everything else is just application logic. If it suits you - stick to that, I think.

Sounds like us

WE are at the point we likely will not upgrade also, we just went from 2.0 with advance distribution to 4.0, talk about expensive, the 2.0 database was working ok, but no more support, no new licenses for it for additional users, no payroll updates, ect.

Now, we can't easily even go to SP1 or SP2 or SP3, since each one adds little besides bug fixes ( we are native database) and each requires a review of all modified objects so see if they conflict. So, it is not even reasonable to be able to apply a service pack without a great expense.

Howdy, Stranger!

Quick Links

Categories

THAT's the point

Comments