Category Archives: Arena Solutions

Eric Larkin, Chief Technology Officer and co-founder or Arena Solutions, a very innovative and powerful BOM (bill of material) management application, describes how Arena Solutions is rolled out on service parts accounts. He describes some of the differences between finished goods implementations of Arena Solutions vs. service part implementations.

____________________________________________

Title: Eric Larkin from Arena Solutions on BOM Management for the Service Market

Here we learned that with regards to service parts, Arena Solutions helps companies know what they build and when they built it. That is they provide a comprehensive revision history. This allows companies that use Arena to ship out to customers exactly the correct service part product version that matches their equipment. A service part BOM (bill of material) management implementation will tend to have more materials, but a less complex BOM structure, so the challenges on the master data side are a bit different, but that the essential process of implementation remains similar. Companies that use Arena often model all products, that is service parts and finished goods in the same implementation. I could personally see a pure service parts implementation of Arena, and on of the reasons could be that the service organization could decide to go with a different BOM solution than finished goods.

Conclusion

This interview is filled with information that should be valuable to anyone interested in BOM management for service parts. I wanted to thank Arena Solutions for letting me record and post the videos here.

Much of the Dynamics AX functionality for supply chain is rather basic. However, there is one supply chain area area which stands out. This is the service management functionality. As Dynamics AX could be connected to a service parts planning engine, I thought it would be interesting to go through some of the screens in this application.

We start off in the introduction screen. This one screen controls all of the functions in Service in Dynamics AX (including configuration).

This is the Service Agreement screen. This where the service agreements are stored.

This is probably the most important screen for those that work in service parts planning because these are the different service agreements that are then connected (in terms of a service level) to the service parts planning engine.

One thing I do like is the ability to perform a drop down off of the bread crumbs and goto other related areas. You could not think of doing something like this in the SAP GUI. In this case we can take a look at the service orders.

Here they are.

Right from here we can go into repair operations, which allows us to fill out a form.

The Service Parameters is essentially the configuration. This looks extremely easy to configure compared to what I am used to SAP. See all the options below.

Selecting any of these brings up the option below.

Here is where the service agreement standards are set (under Setup –> Service Agreements –> Service Level Agreements.)

Here we can setup the diagnostic codes.

This certainly gives the impression that a Microsoft Dynamics implementation would be far more cost efficient than an Oracle or SAP implementation. This topic of configuration efficiency is almost an undiscussed topic, but its one of the most important features to implementation success. See this post on the topic:

This is particularly true coming from the SAP world where reporting is not inherent in the user interface but instead is a separate system called the BW. I prefer at least a basic reporting system within the application itself.

The reports open as listed above, but you can drill down into a specific item for more detail. Interface Speed

The entire Dynamics Trial was slow and buggy. The interface looks very HTMLish, however, the performance is quite bad. You are required to use Remote Desktop to get into the Windows Server 2008 box that is hosting the Dynamics Trial. Why is the trial not simply available to be logged into directly through a browser? This is how Arena Solutions has setup their demo, and their demo system is extremely good and very responsive. Overall it took me quite some time to get these screen shots and navigate through the system because of its performance problems.

Conclusion

Dynamics AX’s service management functionality is not bad. Secondly, Dynamics does a very good job of combing everything from the user screens to configuration to reporting all in a small space. Its “breadcrumb” menu systems is also very good and improves provides a powerful navigation element throughout the system. You never feel as if you are lost as with the bigger ERP vendors.

Dynamics AX is rare ERP software in that it has quite a lot of focus on service management. I assume this is because they purchased a vendor and integrated into their suite. Explicit service management modules like the one in Dynamics AX are important in order to manage the supply chain by service levels. Service parts planning software can plan the supply chain by service level, but it needs to know what the different service levels are, and they must pull them from someplace where they are stored and managed. This is where the Service Management area of Dynamics AX would come in.

It’s only though a discussion with a vendor of “electronic parts catalogs” that we understood that this is the most common nomenclature used to describe what we describe as a service parts database. We cover service parts databases in this post below.

Electronic parts catalogs are complex and have special needs in terms of supersession and detailed service information. Companies like Enigma, combine pure content management (which is a very broad field which incorporates the storage of almost any organized form of readable data) along with procurement decision support, among other functionalities. This type of functionality actually dovetails with bill of material or BOM management software – one example of which is Arena Solutions. However, while BOM management software is primarily used before and item is made, service parts databases (SPDBs) or electronic parts catalogs (EPCs) are used after the products are deployed and ready to be ordered. There is a good reason to integrate the system. As a test case we have attempted to do just this with our service parts portal, which is a simplified service parts database which integrates real time with an Arena Solutions demo system. The web technology of widgets, allows one web page to display the content of other HTML based systems through screen scraping. (we discuss the importance of making 100% web interface supply chain software in this post)

The reason integration it is necessary is because it is important to have new parts, part supersession, and other changes reflected in the EPCs so that the correct parts are ordered. However, PLM (collaborated on by designers, manufacturing and suppliers) has been considered a separate system from EPCs (collaborated upon by parts managers, dealers, and inventory planners).

We were so impressed with Arena Solutions for BOM management and PLM that we decided to create a service around it.

Arena manages bill or materials to in a very sophisticated way. We perceive a real need for capabilities in an area of software for service parts maintenance systems that allow service parts to have information regarding maintenance notes and service part information such repair costs per repair type.

Multiple User Input

One of the important considerations with regard to this type of system is the ability of multiple users. In this way the database can be updated by:

Field technicians

Internal service personnel

Customers (in the comments area)

This combined with making some portions of the database private and some public can bring the best of all worlds in terms of maintenance information distribution.

In our previous post we discussed the different vendors and services offered for reliability testing and prediction. One of the important issues with relation to MTBF management is the product structure. The product structure is the hierarchy (or at least at first glance) of materials that make up an overall product. This has different names depending upon the application. In SAP ECC it is referred to as a Material BOM or an Equipment BOM. In MCA it is referred to as the product indenture network. This survey conducted by Arena Solutions on this topic is quite interesting.

BOM vs. PLM Software

Being able to deal with the BOM in a flexible and distributed manner is increasingly a capability with what is referred to as PLM software. However, that is not right. BOM management is actually a subcategory of the broader term PLM or life-cycle management. Lifecycle management exists in a number of applications in supply chain, as the article below explains.

Having powerful and collaborative BOM management software is important for many reasons that include improving the efficiency of product development and building quality into products as well as product costing for contract development. However, it is also important for service parts planning and MTBF. MTBF calculation integrates with the BOM.

ERP for BOM Management

There is increasing evidence that BOM management greatly benefits from specialized software. ERP software manages how the BOM relates to execution and planning, but does not tend to have advanced capabilities with regards to BOM management. (of course Oracle purchased Agile in 2007, a leader in PLM, however, software mergers often kill the aquired company’s innovation and product. Look how little Oracle has done with the PeopleSoft functionality). Here is an interesting quotes regarding ERP for PLM from Arena Solutions.

There is a misconception that Enterprise Resource Planning (ERP) systems can be used to manage all product information after design, including changes and communication. Unfortunately, even though the final production BOMs, the Item Master, and costing information are ultimately loaded into ERP systems, these systems do not have integral processes for ECOs or file management. Therefore they cannot be used to control BOM or item changes or manage associated files. Furthermore, as a tool primarily for internal groups, ERP systems cannot be used by external partners and suppliers to obtain product information. – http://www.arenasolutions.com/images/pdf/rc_docs/whitepapers/Arena_Turning_Great_Designs_Into_Great_Products_Whitepaper.pdf

ERP systems are not designed to be change control or file managementtools, and must be manually updated to reflect approved productchanges. To update and change product information across electrical andmechanical CAD tools and ERP systems, many companies employ spreadsheetsoftware, such as Microsoft® Excel, to manage part changes, SOPs andBOMs and to communicate them to project teams.” – http://www.arenasolutions.com/images/pdf/rc_docs/whitepapers/Arena_WP_Med_Device_Doc_Control.pdf

Reinforcing this statement is the poor track record of SAP PLM. We personally analyzed this “solution” several times only to find that it did not involve new software as much as simply leveraging the old structures with a few bells and whistles added in.

(in the past several years, SAP product management and marketing is increasingly following the Oracle model of presenting vapor or stretching pre-existing functionality to fit new solutions)

Spreadsheets for BOM Management

Exporting BOM information to a spreadsheet and managing it there for MTBF and other purposes is not a very competitive solution with the other alternatives that are present. In fact, even using an on line spreadsheet like Google Spreadsheets, while better than using Excel with its isolated files, is still not really capable of managing the complexity of BOMs. Furthermore with the rise of contract manufacturing and distributed product development and manufacturing, islands of data created by Excel are even less useful. Amazingly PLM software is still lightly implemented out in the marketplace.

Graphic from Arena Solutions – taken from an online webinar – not a formal study.

As far as ERP systems, while ERP systems have BOM functionality, it is not the functionality offered by Arena. Rather ERP BOM management was developed in order to support transaction processing. This is quite a bit different from what specialized BOM management software does.

Arena Solutions

Arena Solutions’ website is quite good and for anyone interested in PLM and BOM management we recommend a visit. It is of course selling a service, however it is also very educational and most the statements made on the site are reinforced by our consulting experiences.

In one of their white papers we found a very good explanation of the needs of modern BOMs.

“As the design progresses toward production, the part-list-like engineering BOM must transition into a detailed manufacturing BOM that includes all the items required to make sub-assemblies and the final product. During this process, numerous project teams contribute to the BOM and item changes (Figure 2). The resulting manufacturing BOM is highly relational and includes various associated data and files, such as design drawings, software files, item files, costing information, compliance status, specification data, and supplier information.” –

One easy way of understanding this is that one sub-component often is part of more than one parent component. Therefore, by using a relational BOM configuration (which is different from a relational database, you can use a relational database, but still follow a restricted hierarchical model in your BOM configuration.), when the sub-component is changed once in one location it affects all parent components immediately. This is the desired end state, that all parent products be instantly updated when a change to a sub-component is rolled out. This relates to all life-stages of a product’s existence. This updated part data is then sent over the planning system where a flag is changed that tells the planning sytem this part should no longer be planned. Having this data updated is as important as the algorithms you use to produce a forecast.

This complexity really requires a software specialized software solution. Furthermore, this is perfect application for a hosted application. (we increasingly wonder why companies continue to ask for software they have to install and manage, particularly when the application is shared.) With hosted applications, as long as the software provides a standardized feed of some type (such as RSS), application integration can be managed completely on line, so a BOM Management – PLM service provider like Arena could be integrated with an on line version of a transaction processing system and the service parts planning system.

Application Screen Shots

Arena has a nice interactive demo on their website, so we decided take a few screen shots. This screen shows the different status of notifications.

Below we have a listing of notifications for particular BOM numbers. We also see the people (users) that have the ability to view or edit or comment on the BOMs.

Below we see the view for Monica Williams, and the materials for which she has notifications. You can see that each of the materials has an event code attached to it.

When we select one of them we get taken into the detail.

Here we can see who is part of the notification distribution list.

Here we have a flowchart of the process status.

Here we can see that suppliers are involved in this process and can log in.

Also, the individual products that make up the BOM are listed as well.

For each product, there is a coding for the items compliance requirements as well whether the prase of the item (if its in production, obsolete, etc..)

If we select the files, we can see all the attachments to each product.

In conclusion, we find this software very compelling. Furthermore they offer a fully hosted solution which they call on-demand. In our consulting experience, Arena is providing answers for a lot of problems that plague BOM management at many a company.

Open Question

One of the questions we do have is where an MTBF value is located. For the purposes of service parts planning, Arena just needs to feedone number per part. Both SAP SPP and MCA can perform their forecasting(if the option is selected) from a simple MTBF value associated withevery product record. This is called leading indicator forecasting inSPP and causal forecasting in MCA. At least MCA has some involved ways of calculating the overall service level, and one ofthe inputs is the MTBF of the underlying items – related to theinventory coverage for each item.This is something that should naturally be maintained in Arena. How this value is obtained is a different topic and is covered here.

Site Tip

Welcome to the most popular service parts planning blog. This blog is maintained by an independent software consultant with interests in service parts planning, inventory optimization and multi-echelon planning. There are currently over 70 articles on this blog. Comments are very much encouraged.

Search

Search Tip

When using the search box place multiple terms in quotations. Typing the term you seek + "service parts planning" into Google will find articles faster than this search box will. Also, the category selection and tag selection (listed below) are excellent ways to find what you are looking for.

People Behind the Site

Hi, I'm Shaun Snapp and I am the main author and editor at SCM Focus.This blog focuses on the concept of 4PL, which is an experimental area currently. I offer the same project and software knowledge that you see in these articles. Here are some of the reasons people like to work with me:
Access research from multiple previous projects.
Learn leading edge planning approaches. Objective information about software. Select here for more.. Read More...