Whether you're selecting and/or installing a software package or designing custom software, in most instances you think in terms of installing or creating software modules. The advantage is obviously to divide an immense project into manageable parts.
The concept of modularity is also incorporated in software development when using traditional software development tools because it's complex and unforgiving.
In both cases there are significant potential pitfalls...
The Cross-Functional Relationships of Modules
- The relationship between certain modules are obvious. Of course the G/L Module is related to the A/P Module and the A/R Module. But what about the relationship between Order Entry and A/R and Shipping or Production and Inventory Control? How are problems in Shipping communicated back to the Customer Service people?
- Choices... often irreversible choices... need to be made when installing these modules to make these capabilities possible if they have been considered by the software designer. Often they're not considered because the programmers have no idea about the day-to-day operations of a business.
- I can help you because I know what to look for and I know what questions to ask. I also know how to challenge the answers the software vendors give to make sure you don't get "roper-doped".
Problems Associated to Software Modularity and Complexity
- The typical response to requests for cross-functional communication between modules is to provide a report. That's because of the complexity involved and time and expense of going back into the code to make the change the right way. Or you may simply be told "it can't be done".
- The problem with reports is that someone must now pro actively take time and remember to run and scan the report to find out if there are problems. There are times... no matter what procedures are in place or the threats imposed... it doesn't happen or problem goes unnoticed. And that's when a customer is not informed or a late shipment or shipments are made to a customer that's been placed on credit hold. Any number of problems can occur that are totally preventable.
- The problem should be "in their face" prominently displayed as an error message on the screens of every user... regardless of the module... affected by the problem until the problem is fixed. They're passively informed and they can't miss it.
- I can help you with this and it doesn't mean scraping or modifying either the code or the structure of your database in your current system so long as I can access the data. Any database changes would be achieved by creating supplemental tables around the existing database.
- Because modifications are so easy using Magic xpa, expanding this capability to problems as they arise is both quick and affordable.
|
