expandable medtech whitepaper medtech whitepaper ... (mrd) and product (prd), ... these documents...

EXPANDABLE SOFTWARE, INC. 900 LAFAYETTE ST., SUITE 400 SANTA CLARA, CA 95050 1-800-680-6050 WWW.EXPANDABLE.COM

EXPANDABLE MEDTECH WHITEPAPER

Quality Management for Startup Medtech Companies: Design and

Documentation Controls

Expandable Software, Inc.

by Dennis Payton - Executive Director of Product MarketingExpandable Software, Inc.

rvanoveren

Typewritten Text

33

3

4

5

5

6

6

8

8

8

9

9

11

12

13

14

14

161617171818

WHITE PAPER Medtech Design and Documentation Controls

Page 2 Expandable Medtech

Table of ContentsExecutive SummaryFDA Regulation of Medical Device Design and Documentation Controls

US Law and Regulation

Interpreting the FDA View of Design Controls

Key Points of an FDA View of Regulation for Design and Development Model

Developing an End-to-end Product Design and Development Model

Product Design Model with Widening Market Exposure in Process

Basic Generalized Product Development Process Model

Managing the Product Lifecycle

General Cradle to Grave Product Lifecycle

Generalized Product Lifecycle Model

Design, Production and Documentation Control Tools

Key Production and Change Control – ERP/MRP Systems

Key Design Control and Product Lifecycle Management – PLM Systems

End-to-end Control for Product/Item Lifecycle Management

PLM Product Design Release to Production ERP Integration

Key Documentation and Quality Management – QMS Platforms

Document Management and Training Process Flow

SummaryReferencesAbout the AuthorAbout Expandable Software, Inc.Arena Solutions, Inc.AssurX, Inc.

DisclaimerThis brief contains an interpretation by Expandable Software, Inc. of FDA regulation.

The document is intended to be informative and not binding on Expandable Software, Inc. Any

detailed inquiries regarding the

• Pure Food and Drug Act of 1906

• Food Drug and Cosmetic Act of 1938

• FDA or CDRH Regulations

• FDA or CDRH Guidance

should be directed to the relevant governmental agencies responsible for enforcing the laws and

regulations in these areas.



Executive Summary

Some of the shortest descriptions in the FDA CFR 21 Part 820 Quality System regulation are found in

Sec. 820.30 and Sec. 820.40, totaling about a page of written language around Design Controls and

Document Controls. However short, these two sections can be the most complex aspects of Medical

Device controls when actually complying with the regulation.

Fortunately the FDA does give a bit more background to help a new Medical Device Company

understand these two key elements (see Medical Device Quality Systems Manual, A Small Entity

Compliance Guide). With the detailed complexities, even those few pages of guidance (covered in

section 9 Document and Change Control) fall short of providing the coverage needed to understand

their impact on a company’s Medical Device Quality System.

The good news is there are some very good tools that can help mitigate the complexities and

streamline controls. The bad news is that it still takes a very strong detailed and sustained effort to

insure complex controls are in place for continued success and compliance with regulation.

The objective of this brief is to shed a little light on how the FDA views Design Controls and associated

Documentation Control, as well as to provide a high level view of enterprise level software options that

can help alleviate some of the pain in developing and implementing control processes.

With over 25% of FDA issues related to Design Controls, any FDA-regulated business should maintain

a highly focused effort toward capturing design detail, getting approvals, archiving historical design/

design changes and procedural documentation and making sure that it is done with a high level of

collaboration for all stake holders while maintaining rigorous compliance audits.

FDA Regulation of Medical Device Design and Documentation Controls

US Law and Regulation

The two Acts of Congress that provide the basis and framework for the FDA to define and produce

regulation for Medical Devices in the US are:

• Pure Food and Drug Act of 1906

• Food Drug and Cosmetic Act of 1938

A key Medical Device regulation derived from these Acts is the Medical Device Quality System

CFR 21 Part 820 that defines two specific areas:

• Design Control (Subsection 820.30)

• Document Control (Subsection 820.40)



These subsections combined provide a whopping single page of written regulation and can pack

a wallop to a Medical Device’s success or non-success in complying with regulation for the U.S.

marketplace. When the FDA crunched the numbers, they found that 25% of the Medical Device issues

were centered on Quality System compliance, with... wait for it…“Design Controls” by far being the

leader in issues recorded by the FDA with devices in the market (circa August 2011).

So there is no doubt that the two smallest sections of the Medical Device Quality System regulation

have a significant impact on design, development and bringing a medical device to market with

compliance.

Interpreting the FDA View of Design Controls

With a wide variety of Medical Device suppliers there comes a wide variety of processes, procedures

and controls that are developed specific to a business and to the Medical Device(s) being produced. It

is important to understand how the FDA tries to normalize a specific business to the regulation when

auditing that business for Design Control compliance. Having a bit of understanding of their view will

help make for a much smoother comparison, analogy and a much cleaner and successful audit of a

company’s design processes.

A simplistic model can be derived from the 820.30 regulation that the FDA may use to assure design

coverage and compliance of a device design and/or manufacture to the regulation. The design and

development model can be graphically depicted and loosely linked to the regulation as follows:

Figure 1



Key Points of an FDA View of Regulation for Design and Development Model

1. Ensure that there is a logical design and development process flow with well-defined review

stages, gates and/or checkpoints.

• Allow for documented design reviews by key cross functional teams

• Remember that most designs are “living designs” and that change management needs to

be accounted for and built into the process

2. Design reviews should be continually verified against the original design intent with adjustments to

assure an ongoing high level of quality.

3. Final product should also have specific validation against the market/user needs to assure

addressing the market needs while maintaining high quality and high level of public safety.

4. Considering that each stage can have associated documentation, each review can have a

review document, each verification cycle and validation cycle can have its own supporting

documentation:

• All the documents generated throughout the process must be controlled for version,

approvals, communication and training

• Each document associated with a given design (including obsolete, historical, active,

archived, etc.) becomes part of the Design History of that device including not just

the design files (CAD, Electronic Schematics, Source Code, Production Assembly, etc.)

but also the documented review results, QA results, design input documents (market

requirements [MRD], product requirements, design requirements) and other device-related

documentation

Again, like the FDA regulation on Design Controls, this is a very short summary of complex processes,

document definitions, controls and general management and approvals about which volumes of

books have been written. The objective should be to have a very good understanding of how the FDA

or other regulatory entity views the Medical Device controls such that a business can demonstrate

how their particular controls map into the regulatory model. A logical analogy of a company’s design

and development model should be able to map to the regulatory normalized base line model(s), and

in doing so, will result in smoother audits with a higher degree of success and hopefully less time and

expense in managing through the audit process (something the regulatory folks don’t really care about

but as a business we all do).

Developing an End-to-End Product Design & Development Model

Most product managers will view products from two perspectives while developing and managing a

product physically to market, here we are only focusing on the concept to market physical side (there

are of course all the other product management pieces: pricing, market sizing, selling points, etc. that

are equally important but of no concern to the regulatory agencies that are mainly focused on the

public safety of devices rather than the financial business side):

1. PDP – Product Development Process

2. PLC – Product Lifecycle management



These two aspects are key to the regulatory agents in assuring there are controls for the development

and maintenance of devices from cradle to grave. For most any industry this is probably not a surprise

as most modern quality management systems, whether industry driven or government regulated,

require design controls for both the development process and managing changes over the life of the

product(s). The objective here is to present a general model for each of these processes and discuss

key points to be aware of when developing these models specific to a Medtech business or product

development process aligned with the regulator’s normalized baseline design and documentation

perspective.

Product Design Model with Widening Market Exposure in Process

A generalized PDP model this author has developed over the years among various businesses not

only captures the development stages but also depicts an ever-widening product exposure as the

development matures throughout the process. In this general model, the process is broken into stages

where each stage is reviewed not only for design intent for regulatory needs but also for marketing

and business validity (as we need to ensure running a business that meets its financial objectives as

well as meeting the obligations of the regulatory environments) before moving to the next stage.

One can see that this particular model is easily mapped to the FDA normalized regulatory perspective

by adding a few steps. Also as a design progresses to a fully released product one should attempt to

limit the exposure in the early stages and provide an ever increasing product exposure until formally

released to the market.

An important item to note is the initial stage of definition; make sure all functions of the business

have input to the design requirements; both market (MRD) and product (PRD), and acknowledge that

these documents are living documents throughout the process and therefore need to be controlled

requirement documents. Upon kicking off or starting a project the initial exposure of the product is

restricted to Management and Design Engineering for design and development. Then, as the design

matures, exposure to other critical functions is widened for verification, validation and finally full

exposure across all business functions, including regulatory approvals, when made generally available

to the market. Finally once a project is complete all the associated support documents throughout the

process need to be archived and retrievable in support for each product as a complete design history

detailing any changes that are required to maintain the product in the market.

Basic Generalized Product Development Process ModelCross-functional and market exposure modeled against the project schedule over time for each phase

of the development process would look something like the figure below.



Each stage should be a cross-functional review at various points in the development process to

assure the product meets the intended market requirements and is technically feasible, supportable,

marketable and demand creating. Initially, inbound marketing and engineering are heavily involved as

the business cases and technology are proven out. As the evolution of the project heads toward the

market, support and sales take the lead as inbound marketing and engineering resources wind down

in order to take on other new projects including any needed changes to existing product lifecycles

already in the marketplace.

This diagram doesn’t detail out any iterative design and reviews that may occur within the stages or

throughout the process, as it would clutter up the flow and discussion, but a full PDP will need to

detail out each of the stages, define product PDP status (definitions of product in development, alpha,

beta, clinical trial, approved for market(s), etc.), define relevant review documentation and detail out

gating requirements throughout the design of the development process.

In summary, the key points are:

1. Build in initial cross-functional design input up front in the development process before kickoff

and checkpoints for cross-functional review for both market and business needs, at logical stages

of the PDP process before moving to the next development stage.

2. Be sure a logical analogy can be made to the FDA’s normalized view of regulation design control

and any related documentation control.

3. Be sure the product meets the needs (verified, validated, tested, supported, sold, etc.) of the

market for the FDA but also for the business case.

Figure 2



4. Make sure that there is an expanding exposure as the product is developed and that those

exposed to the product have approved working documentation and are properly trained to build,

sell, support and use the product(s) based on their functional support of the product.

Managing the Product Lifecycle

While the PDP is under development another critical piece to develop and overlay is the lifecycle of

the product. Product lifecycles not only apply to finished product sold but also to raw supply chain

products and/or sub-assemblies used on the final product. One of the biggest FDA concerns is dealing

with changes to an existing product as piece parts, sub-assemblies and third party components

inevitably change in the supply chain. Dealing with existing products: obsolete components, end-

of-life, replacement qualifications, etc., are major factors that require diligent procedures to control,

document and archive that overlay the design and development cycle. Finally the finished product itself

will have its lifecycle as business needs and marketing needs/requirements change over time. Both the

supply chain and actual final product life need to be considered when managing the overall lifecycle

and the product development process should account for new development, change development and

product/change introduction.

General Cradle to Grave Product LifecycleA simplistic product lifecycle has some very basic phases of life: research, development, production

and end of life. These can certainly be expanded as needed by a specific PDP. There can be sub-phases

in the development (prototype, engineering build, alpha, beta, archived, etc., level of product status,

for example) but the main concern is to define the lifecycle that best meets the overall objective while

being able to track the various versions of product in development and in the marketing place.

Figure 3



Key points to consider in the development of a specific product lifecycle (PLC) are:

1. General enough to apply to finished product as well as supply chain components

2. Define a solid definition between a research phase and development phase that will meet the

definitions of controls for a particular product

• Note: the FDA can be a bit more flexible with the research phase as far as hard and fast

design documentation but best to make sure there is a clear distinction and definition

built into a PLC and PDP and assure adequate regulatory coverage

3. Perform a clear and clean hand off between Development and Production with all associated

documentation approved and released

• Be sure there is a process built into the PLC to review current product for meeting

needs (both marketing and business) and allow for adjustments/changes as the product

traverses it lifecycle

4. Design a process around the End-Of-Life of a product both from a business perspective (not

to strand any inventory, leave customers without solutions, etc.) but also from a regulatory

perspective in that no product really “ends” – it rather gets archived and stored so that design

history is retrievable (very much like Levi’s…they “never die they just fade away” but the history

must endure)

• Note: although the general case of the PDP provided in previous sections has been

focused primarily on the R&D and production phases of this PLC, the EOL Process is

equally important to define and put in place so that product is properly archived for

future reference, retrieval and audit compliance.

Design, Production and Documentation Control Tools

Developing PDP, PLC and document management processes takes some thought to assure the right

model is put in place at the right time. While a company is starting up it needs enough design and

document control in place to be effective without over-burdening its resources. However, at the same

time it needs to provide a vision toward growth and success by having the ability to expand the scope

of its controls.

As product portfolios become more involved and as the business grows, enterprise tools should enable

communication and collaboration across a larger employee base. Some of the enterprise solutions

that can be utilized at various stages of growth include engineering controls and quality management

features built into Enterprise Resource Planning & Manufacturing Resource Planning (ERP/MRP)

systems, Product Lifecycle Management (PLM) systems and Quality Management Systems (QMS). With

any level of enterprise solution the critical component is seamless integration of design management

with production management to insure that documentation is controlled with approvals and training

records for employees that use documentation to execute.

Key Production and Change Control – ERP/MRP Systems

As a company moves from seed funding toward manufacturing of goods to be sold, the primary

system generally is a fully integrated ERP/MRP system that provides financial controls, manufacturing

planning for lean production, supply chain management, inventory controls, order and order



fulfillment, product tracking and traceability (Serial Number and/or LOT controls), etc., to meet

the needs of a complex medical device manufacturing environment. Many ERP systems also offer

Engineering Design Control and Change Management for releasing product design into the

production environment that offer the basic Design Controls and Lifecycle controls required to release

product design from the development environment to a production environment.

As an example, an ERP system may provide an engineering module that allows the separation of

engineering designs from production designs so that revisions to released products can be managed

and new products can be introduced into the production environment.

Engineering design management contains three critical elements:

1. Engineering Approved Vendors/Suppliers (EAVL) – Engineering and Development working with

new vendors to supply new parts or technologies.

2. Engineering Parts – generally new parts, exploratory parts/technologies, etc. that are being

considered for product design but not yet used in production environment.

3. Engineering Bills of Materials (BOMs) – engineering parts list and associated material, parts,

quantities, etc. that make up a product, sub-assemblies, parts, etc. in support of a top level final

assembly design.

Figure 4



On the production side of the system, there are matching modules for Vendors, Part Master and

Production BOMs that are in active production or have been produced, potentially obsoleted, and

maintained as production records for products that have been manufactured. It’s important to

separate products in design/development from those in production. When releasing to production,

transfer only designs that meets the PDP process for pre-production or general availability with

sufficient controls and approvals.

Engineering Change Management is the second critical piece that allows the PDP controls between

designs and production with approval controls.

Two key elements are:

1. What product/components/piece parts are being released

2. Who needs to cross-functionally approve the release into production

These two elements of change management are optimally handed with an Engineering Change

Notification and the assignment of Approvers to release changes or new product into the

manufacturing environment.

The critical functionality to demonstrate to regulatory agencies or industry quality auditors is the ability

to have separation between product under development control and product that has been released

to production, along with the controls to introduce changes with authorized approvals into the

manufacturing environment.

In general an ERP system can provide a new business in its startup or early market entry stages with

the basic elements to address regulatory requirements by meeting the design controls, development

process and approvals for managing a product from design into production.

Key Design Control and Product Lifecycle Management – PLM Systems

As a company matures and expands in the marketplace its product portfolio, resources and complexity

also expand and options for deeper controls and potentially a more detailed PDP and PLC are required.

There are a number of products on the market that specifically focus on the design development

process and managing the lifecycle of products as well as providing a deeper level of engineering and

management tools to meet the needs of an expanding business.

Product Lifecycle Management (PLM) provides the capability to define product lifecycles and the rules

required to manage products through a development process. PLM systems also provide extensive

interfaces to both the ERP system for production delivery of approved production design but also to

the extensive engineering tools sets that may be involved with electronic designs, mechanical design

and other Engineering CAD platforms. PLM systems also provide extensive tools for evaluating design

and design changes that aid in product or quality audits and managing changes throughout a product

lifecycle.

A PLM system working alongside an ERP/MRP system clearly provides a separation of design and

production. However, in order to assure a smooth, efficient transfer of products from the engineering

environment to the production environment there must be a seamless integration between the two

systems for accurate and timely design transfer with cross-functional approvals required in releasing

product to market.



End-to-End Control for Product/Item Lifecycle ManagementPLM systems generally have tools that allow the end-to-end definition of product lifecycles and

provide flexibility to define various rules to help a business define or refine a development process as a

product is carried from development through end-of-life of the product.

Figure 5

The PLC model shown in Figure 5 takes the general case discussed earlier to a wider PLC (aka Item

Lifecycle as referred to by many PLM systems since the lifecycle can be applied to piece part items,

subassemblies, top-level product, etc.) and details out the initial stages, design stages defining

abandoned designs, and production stages with EOL archival states for deprecated and obsolete

product as well as various production states. At each level a set of approvers can be defined as

products move from stage to stage and should align with a company’s PDP processes and review

stages.

With PLM features in place, a highly robust and flexible product lifecycle and development processes

can be achieved, and equally important, demonstrated in internal audits and external compliance

audits.

There is one critical piece remaining, however, and that is the seamless transfer of the product from

the PLM system over to the ERP/MRP manufacturing production environment that still needs to be

addressed.



Figure 6

PLM Product Design Release to Production ERP IntegrationThe critical piece left is the transfer of PDP approved designs to pre-production/production. This critical

integration piece needs to done accurately and in a timely manner. All PLM systems allow for the

electronic extraction of product data that aligns with ERP/MRP systems. Extracts can be provided in

various formats including Comma Separated Values (CSV) or more modern standard IPC-2571 PDX file

formats.

In general the same three engineering elements we discussed in the ERP section are required: Vendors,

Items/Parts and BOMs for the manufacturing environment but also defined and used are the Vendor

Contacts and Vendor/Manufactures Part numbers. Approved product, product changes and obsoleted

product are gathered up (scheduled or manually triggered) in a CSV file or PDX file and sent to the ERP

interface that pulls the electronic data into the MRP for production planning and production.

An ERP-PLM interface provides adherences to any production business rules for the ERP platform

and should be maintained in the transfer such that manufacturing can accurately produce the

product for the market. With seamless integration, critical business benefits can be realized: assuring

manufacturing is building the correct product, allowing purchasing to stop procuring obsolete

product, making arrangements for last time buys of product that has been planned for discontinuance,

and others. For these reasons it is equally important to involve cross-functional approvals in the PDP

process to avoid unnecessary stranding of obsolete inventory, ramping new supply channels and to

minimize any financial impact of design changes to the overall business.



A PLM system integrated with the ERP/MRP system provides a strong enterprise solution for flexible

implementation of a comprehensive product development process (PDP), including product lifecycle

management with approvals. They provide complete separation of design from production and

accurate delivery of approved design for market production. These two tools greatly enhance a

growing company’s design controls and development processes with a high degree of compliance to

regulatory design control requirements. PLM not only reduces product error but enables companies

to meet increasingly stringent FDA standards with features that allow companies to better manage

design history files and device master records. These along with other features allow for auditable FDA

compliance while increasing the ability to innovate device designs. This leaves only one final and critical

aspect to address in the regulatory items discussed thus far; that is Document Management tools to

address Document Control, Approval and need-to-know training.

Key Documentation & Quality Management – QMS Platforms

Key to any successful regulatory or industry quality system is the ability to manage and control

documents and use relevant, up-to-date and approved documents in a highly cross-functional

collaborative way with stake holders that need to be aware of updates, deprecation of operating

procedures and critical product documents.

In addition to controlling the documents there is a real need to maintain training needs of employees

that are executing on those documents so that users are referencing correct, up-to-date and released

documentation in performing day to day tasks. Without this level of document diligence, the best

PDP or PLC process can fall flat when the controlling design documents (MRD, PRD, Functional Design

Docs, Reviews, etc.) fail to meet regulatory requirements.

Other critical documents may be required to be supported in the product lifecycle. For example,

production assembly documents, build process documents and other related business process

operational procedures, product support documents, and user documentation also need proper

controls. A Quality Management System (QMS) serves as a much wider platform for addressing quality

processes of a regulated business.

Corrective and Preventative Action, Manufacturing Non-conformance, Vendor Quality Tracking, etc.

are among a small subset of quality functions a QMS can deliver, but one critical area relative to design

control is comprehensive documentation management tools and training tools.

Document Management and Training Process Flow

Among the key and most widely used QMS functions is Document Management. Hand in hand with

document management is the ability to trigger training and maintain training records for up-to-date

documentation critical to running the business and obtaining regulatory compliance. Many quality

systems provide for document control and the documents in many ways can be viewed as a product

with its own lifecycle. New documents should be allowed to be created, reviewed as well as existing

documents changed, updated or archived as obsolete or inactive complete with cross-functional

approvals for each stage of the document lifecycle.



Figure 7

A basis of document control and management is illustrated in the process diagram above. This process

flow covers the basics:

1. New Documents – introduced into the quality system.

2. Document Change – ideally with the ability to compare documents against each other for red-line

change review.

3. Document Revision control – as documents change over time revision control is a critical part of

tracking those changes and staying current with the latest approved documentation.

4. Training and Training Records – the human element is key here to be sure that there is a level of

collaboration between the control system and employees that need updated documents and

training on the new procedures… this can be formal or as simple as reading and signing off on

the latest release note changes to a more involved training program.

5. Obsolete Archival – documents that are no longer in the lifecycle of the business are archived and

clearly obsoleted or inactivated for historical retrieval.

To meet regulatory requirements documents are very similar to actual physical product. In fact many

Product Managers view documentation as a component of the product itself. Quality System auditors

also view documentation as critical and the need to control with versioning, approval, release and

archival as being no less important than tracking the product design and development.

Take extra care in building a quality document management process. As with any document they are

only as good as they are communicated and necessary training delivered to employees with document

updates and most current approved procedures followed in day to day execution.



A strong QMS platform can deliver this plus a wide array of other quality functions critical to a

business in meeting the documentation controls and other regulatory quality system requirements.

Summary

It is interesting that a simple written US FDA regulation for design control and document control can

have such a profound impact on a business. Hidden behind those few paragraphs is a mountain of

detail that far exceeds a short white paper. The bottom line is to develop design process, product

lifecycle and documentation procedures that meet business requirements. Maintaining a balance of

effective and efficient processes without over processing or over controlling are keys to running a

successful business.

Highly successful companies start small and generally begin early in the life of a company with an eye

to the future. When growth and business demands expand, their processes become more complex

and products are more diversified to the market. Keeping the quality eye forward with regard to

product, design traceability, cross-functional management and making best use of enterprise solution

tools (ERP, PLM and/or QMS) can make a company’s growth curve much more manageable, while

maintaining strong compliance with required quality regulation.

References

1. TITLE 21--FOOD AND DRUGS

CHAPTER I--FOOD AND DRUG ADMINISTRATION

DEPARTMENT OF HEALTH AND HUMAN SERVICES

SUBCHAPTER H--MEDICAL DEVICES PART 820 QUALITY SYSTEM REGULATION

• Subpart C--Design Controls - Sec. 820.30 Design controls.

• Subpart D--Document Controls - Sec. 820.40 Document controls.

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=820&showFR=1

2. Medical Device Quality Systems Manual, A Small Entity Compliance Guide First Edition (Supersedes

the Medical Device Good Manufacturing Practices [GMP] Manual)

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/PostmarketRequirements/

QualitySystemsRegulations/MedicalDeviceQualitySystemsManual/default.htm

3. Food and Drug Administration San Francisco District, Design Control – An FDA Perspective, FDA

Overview and Presentation, August 10, 2011

4. Arena Solutions – Arena BOM Control User Documentation, Custom Item Lifecycle Phases

5. Generic Requirements for Electronics Manufacturing Supply Chain Communication –Product Data

eXchange (PDX), IPC-2571, November 2001

6. AssurX – AssurX CATSWeb QMS User Documentation, Document Management Process Flow and

Expandable Quality System Corrective and Preventative Action Process Flow



Expandable Software, Inc. 900 Lafayette Street

Suite 400

Santa Clara, CA 95050

408-261-7880

www.expandable.com.

About the Author

Dennis Payton, as Executive Director of Product Marketing, has responsibility to drive both inbound

and outbound marketing efforts for Expandable. Dennis has 25 years of telecommunications,

networking experience, product management, and executive experience prior to joining Expandable

Software. His’ career began at Bell Northern Research, the research and development arm of Northern

Telecom and Bell Canada as a Hardware and Firmware Senior Architect and Design Engineer, where

he developed high speed switching and call processing platforms for next generation Meridian 1 PBX

business switches. Prior to joining Expandable Software in 2008, Dennis played a key executive role

at GoDigital Networks in taking system level products to market and in the exit acquisition by CTDI.

Dennis also played a key role in the founding and initial funding of Intera Systems and in designing and

developing products based on terabit multifunctional switching fabrics. Dennis’ background includes

architectural design, finance, product management, marketing and proven leadership. He holds a BS in

Electrical Engineering from California Polytechnic San Luis Obispo and did his post engineering studies

in software methodologies and neuro-networks at Stanford University and University of California,

Santa Cruz. Dennis has also completed the UC Berkley Haas School of Business Product Management

credential program and leadership development with AMA and Nortel Leadership Development

programs.

About Expandable Software, Inc.

Expandable Software, Inc. develops, markets and supports and enterprise resource planning

(ERP) software suite designed to help fast-growing manufacturing companies maximize business

performance.

Expandable’s fully integrated enterprise solution achieves a low total cost of ownership by delivering

long-term deployment of a single system implementation.

With its unique model of direct sales and support, Expandable minimizes implementation costs and

assures expert ongoing customer support.



Arena Solutions, Inc.

Arena pioneered cloud PLM applications. The company’s products,

including BOMControl, PartsList and PDXViewer, enable engineering

and manufacturing teams and their extended supply chains to speed

prototyping, reduce scrap, and streamline supply chain management. Arena

cloud PLM applications simplify bill of materials and change management

for companies of all sizes, and offer the right balance of flexibility and

control at every point in the product lifecycle—from prototype to full-scale

production.

Based in Foster City, Calif., Arena holds a spot on the San Francisco Business

Times’ Best Places to Work list for 2013.

AssurX, Inc.

AssurX, Inc. provides highly regulated organizations with enterprise quality

management and compliance solutions. With a choice of OnDemand (SaaS)

or OnPremise (licensed) software delivery options, AssurX’s flexible, all-in-

one system automates quality and compliance processes so issues can be

centrally managed. It helps collect, organize, analyze and share information

to better manage and improve quality and compliance performance

everywhere in your enterprise.

Copyright © 2013 Expandable Software, Inc. All rights reserved.