Business Nova – Promote Your Business , Free!

August 24, 2010

Causes of ERP Failures

Filed under: Business — Tags: , — kishore9 @ 5:56 pm

ERP is the acronym of Enterprise Resource Planning. Multi-module ERP software integrates business activities across various functional departments, from product planning, parts purchasing, inventory control, product distribution, to order tracking. ERP has transformed the way multi-billion dollar corporations conduct their businesses. Successful implementation of ERP systems could save tens of millions of dollars and increase employee satisfactions, customer satisfactions and sustain competitive advantages in every-changing marketplace. Corporate executives are often perplexed by the stories that how reputable corporations (Hershey Foods, etc.) have failed miserably and lost ten of millions of dollars in their ERP endures.

The failures of ERP projects are preventable if we can identify the common causes of the failures regardless the companies and industries that implement them.

An ERP system is the combination of ERP software, the business processes that the ERP transforms, the users of the ERP system, and the computer systems that run the ERP applications. The failures of a ERP project is often the result of the failures in one or more of those four components. The failures in computer systems (hardware and operating systems) are much easier to identify and to fix, so we’ll examine the failures in software implementation, business process and user acceptance.

Failure of ERP Software Implementation

Module-based ERP software is the core of ERP systems. Most ERP projects involve significant amount of customizations. Packaged ERP software modules have built-in functionality that work in a standard and simplified enterprise environment. However, every organization is unique in data requirements and business processes. It is the customizations that transform packaged ERP software into ERP software that meets organizations’ individual business processes and operations. Long and expensive customization efforts often result the pass of release deadline and budget overrun. Customizations may make the software more fragile and harder to maintain when it finally goes to production. Major changes may be required in the later stage of the implementation as a result of incomplete requirements and power struggles within organizations

The integration of ERP systems(http://www.sysoptima.com/erp/erp_integration.php) with the IT infrastructures also challenges ERP project teams. The use of appropriate implementation methodologies can often make or break a ERP project. (http://www.sysoptima.com/erp/implementation_methodologies.php)

Failure of Accommodating Evolution of Business Processes

According to Anthony, R. A, business processes fall into three levels – strategic planning, management control and operational control. Organizations continuously realign their business processes of all levels in response to the ever-changing market environment. Many ERP systems aren’t flexible enough to accommodate evolution of business processes. many ERP system need a major overhaul in every a couple of years.

Failure of User Acceptance

The users of ERP systems are employees of the organizations at all levels. ERP projects usually modify the company’s business processes which create extra workload for employees who use them initially. They may not think that the workflow embedded in the software are better than the ones they currently use. Ongoing end-user involvement and training may ease the difficult in organization’s adaptation of new systems and new business processes.

Bruce Zhang has over 10 years experiences in developing and implementing ecommerce and ebusiness systems in various industries. He operates a website http://www.sysoptima.com that automatically aggregates the news and new articles in e-business (ERP, CRM, Supply Chain Management and Knowledge Management) from over 50 sources daily ( http://www.sysoptima.com/newsbot/ ) to help corporate executives, professionals and consultants to keep up with the latest development in enterprise software market. The website offers a knowledge base for understanding business software from a systems perspective.

August 20, 2010

Microsoft Great Plains Distribution, Barcoding, Consignment ? overview for consultant

Microsoft Great Plains ? ERM from Microsoft Business Solutions and formerly Great Plains Software is pretty generic with its standard set of modules: GL, BR, AR, AP, IV, SOP, POP and US Payroll. However, having about twelve years of implementation and customization history ? Great Plains Dynamics, Dynamics C/S+, eEnterprise being Great Plains Dexterity written application has been and still is attractive core platform for third party software development companies to write vertical and horizontal modules, written as well in Great Plains Dexterity. If you have Microsoft Great Plains implemented or under the implementation should have your options in making in-house or outsourced customizations to fit your vertical industry needs. Let’s consider consignment, barcoding and distribution/warehouse management

1. Consignment Sales & Recurring Sales. If your business is bakery, sandwiches or ice cream making ? you probably send recurring daily shipments / trucks to your customers on consignment. You need accurate system with daily predictions and recommendation on the lot size, based on historical data: day of the week, season, holiday, etc. This is very popular Dexterity customization, dealing with SOP (Sales Order Processing) and IV (Inventory Control) modules

2. Trucks Scheduling / Distribution. In the case of consignment sales you may have your own fleet of trucks. Then for each truck you should have SOP orders batch and you need to print picking tickets. You should first print the picking tickets for the longest route and then one-by-one up to the shortest route. This is also Dexterity customization for SOP module.

3. Barcoding, Warehouse Management. Lot number tracking, Receiving, Order Fulfillment, Inventory transfer and Cycle Count could be automated with Barcoding. Barcode scanner could automate picking list allocation by reading first picking list number and then scan items and quantities ? and doing so ? allocate Items for Sales Order in Sales Order Processing. Usually you write Visual Basic application or routine to work with the scanner and then communicate with Microsoft Great Plains SQL database ? more precisely ? with Sales Order and Inventory tables: SOP10100. SOP10200, IV00100

4. Wholesale ? daily sales and comparisons, profit by item and salesperson. Yes ? all these calculations could be pulled from SOP historical and work tables, item sales analysis, etc. You can deploy Crystal Reports and even Datawarehousing solution to pivot your cube. If you need fixed number of reports and criteria ? you may need again Dexterity or .Net application to arrange reporting data

Considering Microsoft Great Plains ? majority of the logic above is implemented and could be implemented in Great Plains Dexterity. Alternative platform would be Microsoft C# or VB.Net ASPX web programming with Microsoft Great Plains at the back end. You can use such tools as eConnect to work with Great Plains object creation and retrieving or go ahead with direct SQL Stored Procedure. To certain level you could use legacy technologies, such as Great Plains Modifier with Continuum for VB, VBA scripting, etc.

Good luck and you can always seek our help in customization, implementation, integration and support. Call us: 1-866-528-0577 or 1-630-961-5918, help@albaspectrum.com

Andrew Karasev is Chief Technology Officer in Alba Spectrum Technologies ? USA nationwide Great Plains, Microsoft CRM customization company, serving Chicago, California, Arizona, Texas, Florida, Georgia, New York, Australia, UK, Canada, Continental Europe, Russia and having locations in multiple states and internationally ( http://www.albaspectrum.com ), he is Dexterity, SQL, C#.Net, Crystal Reports and Microsoft CRM SDK developer

Microsoft Small Business Manager eCommerce ? Overview

Filed under: Business — Tags: , — juandyliem @ 11:55 pm

Microsoft Business Solutions Small Business Manager is scaled down Great Plains Dexterity based version of Microsoft Great Plains or former Great Plains Dynamics/eEnterprise. Small Business Manager first release 7.0 and all the following version was available on MSDE (MS SQL Server 2000 with limited usage and database size ? 2GB maximum). It is nice situation on the market in eCommerce niche ? we see huge number of customers, who have purchased and implemented SBM for their small and mid-size businesses and then realized that customization options for Small Business Manager are very limited: in comparison to Great Plains SBM doesn’t have VBA/Modifier, it has very restricted version of Integration Manager. These restrictions lead you, eCommerce developer to direct SQL programming. Again ? being scaled down version of Microsoft Great Plains ? Small Business Manager has a legacy of relatively complex tables structure. tom stored procedures way here:

1. Tables Structure. Small Business Manager has similar to Great Plains structure and similar System DYNAMICS database and the company. As you could see tables structure in Resource description in Great Plains ? so you do in SBM

2. Stored Procs. Yes ? we can go ahead and create stored proc in DYNAMICS and companies databases or Small Business Manager. Now ? there is one issue. Technically Small Business Manager comes with MSDE and MSDE doesn’t have lovely tool SQL Server Enterprise Manager with Query Analyzer, etc. So somehow you should deal with this. If you have consulting programmer ? she or he can connect to your MSDE installation, using MS SQL Server Enterprise Manager, installed on consultant’s laptop

3. Visual Studio.Net. This is the development tools to use ? because you will need a lot of web-debugging, considering complicated tables structure and records workflow. Some developers might suggest to use VS.Net data designer to link to Great Plains tables ? this idea is rather very difficult to realize, because of the simultaneous population of multiple tables, while creating internet orders: Order Header, Order Lines, Order Comments, Customer Master, Customer Address Master to name a few. So we would recommend sticking to stored proc.

4. SOP. Sales Order Processing. Usually eCommerce solution works around Sales Order Processing tables. The reason is ? it works with Inventoried items and typical eCommerce is ordering specific items off the internet. Look at SOP10100, SOP10200 and other tables with SOP prefix. Also you should know that SOP1XXX ? are so called working tables and you populate mostly these, when orders are transformed to invoices, order record goes to SOP3XXX tables ? these are called historical

5. RM. Receivables Management Module ? When Sales Order Processing Invoices are posted ? they create record in Accounts Receivables or Receivables Management Module. RM has RMXXXX tables and the ones you are interested to know are RM00101 ? customer master and RM00102 ? customer address master

6. Batch Processing. We recommend you consider just order creation via web interface. Then these orders should be processed by operator in Small Business Manager

Good luck with implementation, customization and integration and if you have issues or concerns ? we are here to help! If you want us to do the job – give us a call 1-630-961-5918 or 1-866-528-0577! help@albaspectrum.com

Andrew is Great Plains specialist in Alba Spectrum Technologies (http://www.albaspectrum.com ) ? USA nationwide Great Plains, Microsoft CRM customization company, serving clients in Chicago, Houston, Atlanta, Phoenix, New York, Los Angeles, San Francisco, San Diego, Miami, New Orleans, Toronto, Montreal and having locations in multiple states and internationally

August 17, 2010

COSMIC: A Small Improvement on the Symons Method

Filed under: Business — Tags: , — slpic256 @ 5:59 pm

The COSMIC FP (function point) software quality metric, is no longer ‘proposed’ but an actual system in use and internationally recognised, whereas MarkII, like other older systems, is not recognised anywhere, and, even in the UK is in decline if not actually dormant, so this debate is already over.

Historically, from my limited understanding of the situation, it seems that originally there were upwards of 35 variants of function point style metrics until the ISO developed criteria for a acceptable solution, ISO 14143: Parts 1 to 5 (1995-2002):

The COSMIC group reviewed existing functional size measurement methods, namely the work done in the late 80′s by Charles Symons in the UK. The aim was to improve on Albrecht’s size index (IFPUG FPA)

As stated in many sources, the most important feature of the COSMIC method is that, unlike Mark II, it was developed alongside the emergence of the newer software applications that did not exist when Mark II was devised, thus being compatible with modern software engineering concepts and unlike the previous metrics, this method was designed to be compatible with the ideas from structured analysis and design.

Because of these two features, COSMIC has Full ISO recognition and is has inherent flexibility for a wider range of software, this flexibility also makes the metric less sensitive to mistakes during analysis than is typically the case with the Mark II metric which does not have the same ability to capture size from multiple viewpoints

Function point style metrics estimation algorithms involve applying a set of rules and procedures to a given piece of software as it is perceived from the perspective of its Functional User Requirements. As size measures are not very precise, this gives a veneer of science to what is in effect a guessing game.

The result being that while Mark II can be used for sizing of the GUI and real-time systems which did not exist when it was created only after extensive adaptation, but which itself creates difficulties of interpretation due to conflicting procedures and rules.

An important issue with the Mark II method is that the "functional components of the method are difficult or subjective to interpret" 6, different measurers will get different results.

The COSMIC method of sizing the functional requirements of software has been approved as an International Standard (ISO/IEC 19761:2003). and unlike the previous variations, COSMIC is the first method to be designed by an international team, as opposed to being the product of one academic or entity. This is a positive because it will help standardisation which will in turn improve repeatability of the measurement.

The most important disadvantage to Function point methodology is that "it takes several days to learn function point counting and more time to become proficient. This hurdle has limited the pool of trained counters." 3 Many of the sources I looked at included warnings such the following "Function Point Analysis should be performed by trained and experienced personnel. If Function Point Analysis is conducted by untrained personnel, it is reasonable to assume the analysis will done incorrectly." 4

Function point methodologies are designed around the application of complex rules and procedures that result in a numerical "value of a quantity"2 representing the functional size of the software.

Unlike the Mark II method, COSMIC requires an extra step to identify layers’ before indentifying the system boundary, however this process enables the analysis to better account for the inner workings of a complex system and reduces the probability of missing functions.

The general consensus from the materials that I have read is that fundamentally the measurement effort for COSMIC is similar to that needed for established sizing methods. However unlike the other methods, COSMIC functional size method is ‘easy’ or ‘reasonably easy’ to apply.

This is in part due to the removal of the technical adjustment factors from the specifications and simplification of the transactional functions rules and terminology. Fore example, using Mark II "a function is not a point unless specific rules are satisfied"3. Where as COSMIC counting rules consist of "three core rules that establish which observations constitute a point"3.

An important factor in general ease of use is the underlying mathematical framework for quantifying and summarizing function points but which involves a loss in information when summarized into unadjusted function points.

Using COSMIC there is no separate counting of files (ILF and EIF) and is Ratio/Absolute. We would identify for each functional process, the subprocesses (entry, exit, read, write); The measurement Viewpoint allows "all functions to be included in the size measure" unlike in Mark II method, then apply measurement function as follows; FP Size = Sum(number of Entries ) + Sum(number of Exits) + Sum(number of Reads) + Sum(number of Writes)

"The size of a functional process is the sum of its data movements (entry, exit, read, write) and the size of a piece of software is the sum of the sizes of all of its functional processes." 6.

Due to the concept of data movements as opposed to Logical Files once per system used in the Mark II, COSMIC results in amore accurate size measure for the complexity of processing stored data.

For example, in the given case above it is not unreasonable to expect the update inventory transaction input to the Inventory item entity to be output during the transaction and become part of the input the inventory_item entity this is information is lost.

Under Mark II rules, it is counted as an input once when the data crossed the application boundary, but not as an input in the Invontary_item entity because the data does not leave the application boundary again at that point.

For the update inventory transaction under Mark II we can a UFPI count of (0.58*9) + (1.66 * 4) (0.26*1) = 12.12, under CosMIC we would arrive at an equivalent count of 3+5+4 =12

In conclusion, the fact that function points are not (yet) a perfect measure of an application, COSMIC does represents an advance over the IFPUG and other ’1st Generation’ FSM Methods. Measurement of functional sizes can be more plausible, easier to make and repeatable.

However functional size measurement technology must keep evolving to meet market needs. indeed I would think that this is too subjective to be counted as a “measure”. For instance, I personally know over 120 software developers at 20 different companies, and nobody had ever heard of Function Points before I did.

The addition in COSMIC of the concept of internal layers, for better identification of component to component interaction allows for more complete analysis, and is missing from MarkII. What is still needed is a defined standard for adequate precision and an effective way to describe the accuracy of the function points which could be achieved in fact through better guidelines. Due to the fact that COSMIC is free and accessible anywhere in the world it is more likely to survive and evolve, unlike MarkII which is UK only, and proprietary.

Bibliography
[1] Abran, Alain, Robillard, Pierre N., “Function Points : A Study of their Measurement Processes and Scale Transformations”, Journal of Systems and Software, May 1994, pp.171-184.

[2] Steve Neuendorf. (2001) Let Size A = X Function Points, Online, http://www.serv.net/~steve/Let%20Size%20equal%20FP.htm, October 22 2004.

[3] Steve Neuendorf. (2001) Evolving Function Points, Online, http://www.stsc.hill.af.mil/crosstalk/2001/02/fischman.html, October 25 2004.

[4] Symons, C.R., ‘Function Point Analysis: Difficulties and Improvements’, IEEE Trans Software Eng., vol 14, no. 1, Jan 1988

[5] Total Metrics. (2001) Function Points FAQs, Online, http://www.totalmetrics.com/cms/servlet/main?Subject=Content&ID=165, October 22 2004.

[6] Unkown. (2002) Advantages of the COSMIC-FFP method, Online, http://www.cosmicon.com/advantagecs.asp, October 25 2004.

I am the website administrator of the Wandle industrial museum (http://www.wandle.org). Established in 1983 by local people determined to ensure that the history of the valley was no longer neglected but enhanced awareness its heritage for the use and benefits of the community.

August 14, 2010

Great Plains Dexterity ? Microsoft Great Plains Customization Overview

Microsoft Business Solutions Great Plains, former Great Plains Software Dynamics and eEnterprise are Dexterity-written applications. Also small business line: Microsoft Small Business Manager or Small Business Financials is written in Dexterity and uses the same code base as Great Plains.

The history of the Dexterity. Great Plains Dexterity – is proprietary programming language and technology, designed back to earlier 1990th with the goal to build platform independent graphical accounting package – Great Plains Dynamics. Dexterity itself is written in C (following popular those days hope – that C will provide platform independence). You can install Dexterity from Great Plains 7.5 CD #2. Obviously it requires a lot of learning / training, but it allows your custom piece be seamlessly integrated with Great Plains interface.

? Native Dexterity Cursors. Dexterity was designed as platform independent programming language and so if you want your code to be operable on all currently supported databases – you use Dexterity ranges and loops to manipulate the records

? Great Plains Dexterity with SQL Stored Procs Nowadays, most of Great Plains installations are moved to SQL Server – so you can use Dexterity for custom forms drawing only and make the buttons run SQL stored procedures.

? COM Objects calls. Beginning with version 7.0 Dexterity supports COM objects – you register them as libraries in Dexterity. Refer the manual. This technique allows you to call such nice things as web services across the internet.

? Dexterity Forms – if you like VBA and are comfortable to do all the business logic in VBA – you can use Dexterity as new forms creator/editor. This is OK – but you have to purchase VBA/Modifier and Customization Site Enabler from MBS.

? Great Plains Alternate Forms. These are modification to existing forms ? the ones found in DYNAMICS.DIC. The most popular customization are made on SOP Entry form. If you are designing your customization ? we recommend you to avoid alternate forms ? the problem is customization version upgrade. In the case of alternate form ? customization should be redone.

Some restrictions. Great Plains is actually integration of multiple dictionaries: DYNAMICS.DIC, ADVSECUR.DIC, EXP1493.DIC, etc. In your Dexterity customization you can deal with one dictionary – DYNAMICS.DIC. If you need cross dictionaries customization – consider using SQL Stored Procs for crossing dictionary borders and pulling data/making changes in the other dictionary.

You can always have us help you with the customization. Call us: 1-866-528-0577, 1-630-961-5918.

Andrew Karasev is Chief Technology Officer in Alba Spectrum Technologies ? USA nationwide Microsoft CRM, Microsoft Great Plains customization company, serving clients in Chicago, California, Texas, New York, Georgia, Arizona, Louisiana, Michigan, Florida, Canada, UK, Australia, South Africa and having locations in multiple states and internationally ( http://www.albaspectrum.com ), he is Dexterity, SQL, C#.Net, Crystal Reports and Microsoft CRM SDK developer.

Older Posts »

Powered by WordPress