Christine Longwell さんのグループアクティビティ

Agile Supports Faster Upgrades

Christine Longwell — Tue, 19 Oct 2021 17:03:00 GMT

Successful digital transformation is not a static initiative. Simply implementing a system or systems, no matter how perfectly they meet your current business needs, cannot anticipate the needs of your business in the future. Business needs are constantly changing, and Aras Innovator is constantly adapting to meet and anticipate customer and market needs. Unlike many other PLM companies, Aras introduces new functionality with every release. New Aras functionality is typically released every 6-8 weeks, which is a major market differentiator. Functionality is not held back and rolled out in large chunks years later, but it’s dropped in each release. This enables customers to choose when they want to take advantage of it. As a result, our customers upgrade more often.

Aras customers are more aware than most PLM users that continual improvement is not optional, and digital transformation is a journey, not a destination. The Aras agile deployment methodology translates into the agile, rapid upgrades that Aras customers are accustomed to taking advantage of as part of the subscription cost.

Aras Upgrades are faster and cheaper

A recent report by CIMdata demonstrated that Aras Innovator upgrades are faster, cheaper, and generally less painful than upgrades with other PLM systems. More information on the report can be found in a blog by Mark Reisig, titled, Which PLM Vendor Keeps You Most Current? The CIMdata report details the value of staying current, but this blog we will answer the questions: how Aras achieves this for our customers, and why our customers succeed in this rapid turnaround into the latest version. If your upgrade is cheaper and faster, why not take advantage of the latest technology and features more often?

Business process

Aras is different. Fast and easy upgrades are in our DNA. We are committed to performing upgrades as a part of your Aras subscription. Naturally, this means we have some skin in the game, and our software is fundamentally developed with easy upgrades in mind.

Another important differentiator is the Aras upgrade team. Other companies treat upgrades a lot like a professional services engagement and charge accordingly. Our Professional Services team is focused on the implementation and continuous improvement for our customer base. Our dedicated upgrades team is solely focused on upgrades with the pure mission of getting in, executing the upgrade, and getting out as quickly and elegantly as possible.

Platform

So, what does it mean to have a platform that is built for upgrades? As a platform, with applications sitting on top of it, Aras Innovator is designed to upgrade the platform without disturbance to the applications.

Apple and Android are two examples of platforms with applications. Most cellular consumers have had the experience of upgrading their phone. Moving from one Apple device to a later model is fairly easy. There's no need to re download or configure existing applications, and all of your customizations are carried over. Now imagine if the underlying architecture of the phone was different each time. Upgrading your phone would look a little more like moving from an Apple to an Android phone each and every time you perform an upgrade. You would have to reinstall and reconfigure all of your applications in a different environment each and every time. There would be a learning curve, and while, at most, applications would look similar, the subtle differences would take a while to get used to.

Personally, we are an Apple family (no judgement). As the mother of two teenagers, I simply don't have time to manage and troubleshoot phones and tablets on a different platform. Like the Aras upgrade team, I am experienced in Apple nuances. If my kid drops their phone in the lake, which has happened, I can have another one up and running in less than 24 hours. It’s just a matter of moving the database over and implementing some minor customizations. Sure, the kids will have to tweak some settings and application preferences, but generally they are seamlessly up and running in about a week.

Customer success

If free upgrades sound too good to be true, check out what our customer Insitu has to say about keeping current in this video case study, Insitu’s Upgrade Success Story. They discuss how it is very costly to upgrade with other vendors, and how the company benefits from emerging features.

Upgrades and continual improvement

Aras customers generally have a culture of continuous improvement – from embracing agile implementation, to a commitment of a DevOps culture. Rapid and frequent upgrades are just another piece of the Aras customer philosophy. If your PLM system is more than five years old, maybe it’s time to start questioning why, and whether your vendor is committed to your continual improvement and uniquely evolving business needs.

Do you Love Your PLM?

Christine Longwell — Tue, 09 Feb 2021 15:47:00 GMT

I was listening to a customer the other day who complained that he was so frustrated with his old PLM that he basically “wanted to throw it all out and build a functional system himself.” I had to laugh at the number of times I’ve heard that in the last 20 years. In fact, Aras put out a wildly popular sticker saying, “I love PLM.” Its popularity did not stem from an actual affinity for PLM systems in general, but because of the irony that most PLM systems are just so frustrating to work with. Keeping one on my laptop has led to some interesting airport conversations over the years!

So, let’s dig into why people are typically frustrated with PLM.

It dictates the way you work.

Sure, PLM fundamentally centralizes and organizes data into a unified structure. If you are a design engineer conducting a thought experiment and designing something in a vacuum, you certainly don’t need PLM.

On the other hand, for product manufacturing organizations, requirements guide design, design feeds data to purchasing and manufacturing, which feeds information to service, and quality closes the loop back to design and requirements. Without a unified system that tracks part interdependencies, “where used,” and data relationships change management become simply impossible to keep up with.

While some data governance is necessary, the frustration really hits home when companies try to use software strictly out of the box. All companies have different processes and for many good reasons. Without customizing your PLM to suit the way you work, you end up working for your PLM, rather than your PLM working for you.

Aras’ industrial low-code platform makes it undeniably the easiest major PLM system to customize. In fact, many Aras customers build all sorts of applications using Aras platform services to suit their unique needs. Check out Build With Aras for more on that. What can you build with your PLM?

It’s SO expensive.

Of course, cost varies, and the sky is the limit when investing in product development software tools. Costs will naturally vary when looking at full PLM vs. design engineering centric PDM or even simple BOM management tools. What can be even more costly are mountains of scrap, ordering the wrong versions of parts, project delays, part failures, wiring harnesses that aren’t compatible with the electronic components, recalls due to software incompatibilities, etc. So, while IT systems may be costly, this group of issues is not only costly, but can also lead to people being fired due to recalls, scrap, or generally poor documentation.

The real problem lies with perpetual inability to clearly estimate cost over time once you consider add-ons, various other licenses, and the discounting that is common in the first year or two. In fact, with many PLM vendors, the quoting process alone can take weeks, or even months, and by the end it still isn’t clear that you have the necessary ingredients to finish the job without some additional obscure middleware.

Aras’ pricing is simple. In fact, it’s on the website. Subscription prices per user are all inclusive, so there is no figuring out how many “editor,” “reader,” “contributor”, etc. licenses you need.

You can download it for free. Training is included with subscription, so there aren’t any surprises there.

It takes years to implement...

…and by the time it goes live the business needs have changed.

While this is true with many PLM systems, again Aras is different. Using an agile deployment methodology, customers are working to solve their most pressing issue in months, not years. Both Microsoft and The Air Force Research Laboratory selected Aras specifically for its agile deployment capabilities and ability to customize. After all, implementing the right PLM is a journey not a destination.

Another common issue is that by the time you actually get some systems deployed, there is a new version available. Fortunately, Aras has you covered there as well with free upgrades for subscribers—including any and all customizations.

So, if you don’t love your PLM maybe you are in a relationship with the wrong vendor. Like relationships, optimizing your PLM can take time and effort, but I can guarantee you that it’s going to be easier if you’re working with an open, cooperative, flexible partner. Ideally, this relationship is going to be long-term—growing and evolving over time, while supporting your organization’s changing needs and allowing you to be ready to respond to rapidly shifting environments. A healthy PLM relationship meets you where you are and can adapt to your business process. It won’t force you into a box and hold your data hostage.

Do you Love Your PLM?

Christine Longwell — Tue, 09 Feb 2021 15:47:00 GMT

So, let’s dig into why people are typically frustrated with PLM.

It dictates the way you work.

It’s SO expensive.

You can download it for free. Training is included with subscription, so there aren’t any surprises there.

It takes years to implement...

…and by the time it goes live the business needs have changed.

Nice Blog!

Wed, 13 Jan 2021 11:24:47 GMT

Receive 5 comments on a blog post.

Rectifying the Bill of Materials with the Bill of Process: A Story of Nouns and Verbs

Christine Longwell — Tue, 05 May 2020 14:00:00 GMT

The following is a story of an aggressive startup company that was developing, and hoping to move a highly complex, electromechanical product into scale production.

From a design engineering standpoint, the Bill of Materials (BOM) was derived from the CAD documents.The BOM was then scrubbed to identify make, buy, and phantom parts and passed to ERP to procure the necessary parts.

In parallel, a team of fabricators who created the prototypes worked with manufacturing engineers to focus on building production units―documenting the process steps as they went along.
Sounds great? Well, production utopia was not achieved. The first problem that emerged was the fabricators were requesting parts from the warehouse that weren’t there. Why? Well, Engineering had no knowledge that they were ever used. The second problem that became quickly apparent was the rapidly growing pile of scrap that containing “production parts” that didn’t seem to actually be used to build the units.

It was at this point that I developed a working theory. Either we needed to:

Understand every part that was needed, and where and how to install it, or
Document the steps needed to build each unit and establish a complete list of parts that were required to complete the process plan

A 70% understanding of either of these data definitions was clearly not going to work. At this point it became clear that Design Engineering was responsible for defining the parts for the system (the Nouns) and Manufacturing was responsible for the correlating process steps (the Verbs) of how the parts are assembled. This is when the blame game traditionally starts. Design Engineering insists that Manufacturing Engineering just build according to the CAD dataset, and Manufacturing insists that there are parts missing or unnecessary to complete the assembly tasks.

It became clear that what appeared to be a full CAD dataset was insufficient to manufacture a product. It similarly became clear that a manufacturing plan could not be enacted without all of the parts being specified and ordered.

Engineering produced a Bill of Materials (BOM), Manufacturing developed a Bill of Process (BOP), and at the end of the day these two “lists” needed to be rectified. If a part in the BOM (nouns) did not have a correlating step on the process (verbs), it did not get installed. If the BOP called for parts not in the BOM, they were not available for manufacturing to assemble because they had not been purchased.

Moreover, add rapid engineering design changes, an email-based release system, and variability between units, and you have the scenario for a complete production nightmare.

Engineering release into Production

Traditional design methodology has an initial release from design data into a manufacturing environment where manufacturing engineers dig through the assembly to establish how the product gets assembled. At this point a manufacturing process plan is born. Historical “Over the Wall” methodology demands that the entire product is released at once, and this creates a hurry up and wait scenario for manufacturing planners. Of course, there are several benefits to be had if Design and Manufacturing disciplines are working in the same system. First, manufacturing engineers can begin to build out process plans (BOPs) as the design evolves, and second, they can let the designers know in advance if any of the design parameters are difficult or impossible to manufacture and offer alternatives earlier in the design process, thus avoiding rework.

Most importantly, if every part on the Engineering BOM (eBOM) is used by a process step, it is marked as “consumed” by the BOP. If a process step needs parts that do not exist in the eBOM these parts can be requested while the design is still ongoing. If a step requires more of a particular part, such as a sensor, fastener, wire, or hose, the parts are considered “overconsumed,”, meaning the eBOM has to take into account more of that part.

In this way, design and manufacturing engineers working together early and often ensures that a product will launch in an optimal time. Most importantly, the parts that make up the product need to equal the parts needed to build the product, and this rectification is critical.

Change

One challenge with working in parallel is managing the release process and engineering change orders. In a pre-release and launch scenario change happens rapidly and it is positively impossible to link the changed parts to the changed processes, and the other way around. On-demand, real-time rectification of parts to processes is crucial to ensure that changes flow to production without creating piles of scrap or further propagation of known quality issues. Systematic rectification of designed parts with manufacturing plans is crucial. A view into how Aras manages this rectification is available in a short video here.

At the end of the day, you either need to know 100% what you are making, and parse that into steps, OR you need to know all of the steps needed to make something and have access to all of the correct parts to complete the steps. Of course, in the real world, both methods are identical! You have both the parts and the process defined. When either your BOM (nouns) or your BOP (verbs) don’t align, clearly action needs to be taken, designs or processes need to be modified, and everything needs to balance out.

The Myth of the Magical Data Lake

Christine Longwell — Tue, 10 Nov 2020 15:00:00 GMT

Since their inception, IT organizations have fought valiantly to “put an end to data silos.” While the battle cry was universally accepted, the tactics of achieving this feat have varied. About 10 years ago, the term Data Lake was coined to describe a unified repository for all corporate digital data. The idea naturally sounds perfect to anyone looking at implementing machine learning, AI, or big data analytics. As with many great ideas, the challenge is in the execution. After all, if all of your corporate data lives in a single place, don’t you have everything you need to naturally integrate your systems? (Hint, no.)

According to Wikipedia (the indisputable single source of truth on the internet) a Data Lake can range between data dumped in its natural, unprocessed form, to data that has been somewhat categorized and structured. While it might sound like a great idea, consider what if one source speaks Polish and another French, while one talks about fashion and the other discusses auto mechanics? Yes, you have a bunch of information, all in the same place, but suddenly it is all out of context!

Enter the Data Warehouse. For the sake of the analogy, we are now going to take all of the content, translate it into Latin (who doesn’t love Latin?), sterilize it, and neatly file it away into a data store to run analytics out of. Surely now we have all of the necessary components for cross functional integrations to break down those nasty data silos that were the original problem. Well… no. Data Warehouses aren’t designed to be all-inclusive, particularly of unstructured data, and the information still loses context through the sterilization and transfer process.

So, the latest term floating around, with a highly negative connotation, is the Data Swamp. Information Age warns that without proper data hygiene, governance, or control of the “unstructured data content” your data lake will become contaminated by essentially unusable data that infinitely propagates without benefit to the company.

I object to the word “Swamp” being used in such a negative manner, as one of my favorite local parks is a beautiful and flourishing wetland that is anything but dead, decaying, or useless. The Conestee Preserve is a beautiful ecosystem where streams meander in and out of various marshlands forming a flourishing habitat for beavers, turtles, deer, and The National Audubon Society has designated the park as an “Important Bird Area of Global Significance.” 13 miles of trails and boardwalks ensure that even humans can explore the preserve without impacting the flow of this beautiful marshy environment.

The “Natural Ecosystem” analogy best describes the Aras integration philosophy. Every company has an IT Ecosystem. How healthy is yours? Rather than attempting to force your data to perform “unnatural acts,” our open and transparent philosophy enables data to flow unencumbered where you need it. Learn more about Aras’ Integration capabilities.

The Myth of the Magical Data Lake

Christine Longwell — Tue, 10 Nov 2020 15:00:00 GMT

A Platform Recipe for Success

Christine Longwell — Tue, 29 Sep 2020 14:00:00 GMT

When you look at the PLM market, the word “Platform” is used quite a bit. However, depending on what you are looking at, that word can take on a broad variety of meanings. On one hand, this could mean that all applications use a common data model, user interface, and data repository, while on the other hand, the term is used to refer to a range of disparate applications that are owned by a single vendor. So, how cohesive is your platform and why does it matter? The answer can be found in a rather unexpected place—the space that houses the building blocks that make up applications, or in Aras’ terms, platform services.

Who cares how applications are developed as long as they work? Well, there are several reasons that a unified platform, using Service Oriented Architecture (SOA), is ideal from a business perspective.

Customization & Custom Applications – Aras’ Service Oriented Architecture not only enables our developers to reuse services to build applications, but it also empowers our customers to use these same building blocks to develop their own applications. For example, if you wanted to build an application to facilitate the unique way your organization responds to cost inquiries, you could leverage pre-existing security, workflow, visual collaboration, and reporting functionality and customize—versus coding it all yourself.
Maintenance & Upgradability – When applications are architected in a common manner they are far easier to maintain, thus lowering the burden on IT. As the Aras platform undergoes rapid development, services are improved and new services are added. When it comes time to upgrade your platform, users of all applications on the platform gain the benefits of the upgraded services. The benefits of upgrading multiple applications with a single project will appeal to any IT department, particularly if it is included in your subscription price.
Consistent User Interface – When all applications (including custom ones) are built with the same building blocks, they naturally have the same look and feel. The use of platform services ensures that visualization, searching, reporting, collaboration, and many other aspects of each application are identical. Commonality between applications also reduces the need for training and reduces the number of logins to one.

Reusing Services Enables Industrial Low-Code
The Aras library of services is broad and constantly developing to make the overall platform stronger and more versatile. While there are too many services to list here, they fall into certain functional groupings around access, collaboration, visualization, etc.

While these platform services can be as fundamental as authentication, workflow, versioning, or reporting they also can be called upon and reused to create more complex services such as Secure External Access, Visual Collaboration, or Dynamic Product Navigation.

This services upon services approach creates trickle up functionality for overall applications. For example, performance or functional improvements to the workflow platform service will ripple through applications, and every time improvements are made to search functionalities, larger services like Dynamic Product Navigation and Graph Navigation realize the benefits of these improvements.

Architecture Matters
At the end of the day, architecture matters. Service Oriented Architecture enables an open, flexible, scalable, and upgradable platform in ways that rigid, side-by-side applications simply cannot. In fact, in Mark Reisig’s blog on the subject he points out:

“I contend that more functionality in a given area is useless, if you do not have an open, flexible and sustainable platform that allows you to take advantage of it. If you cannot “plug and play” and seamlessly stream product data across your Digital Thread, then all you have done is added another disconnected island of functionality. These chunks of monolithic architectures “end up looking like pools of mud” (Simon Brown).”

If your “Engineering Platform” relies on applications that are built with different data models using different components and various methodologies, can it really be considered a “platform” at all? If your platform is not built on the same pieces—what you actually have is a bucket of tools.

Whose Data Is It Anyway?

Christine Longwell — Tue, 16 Jun 2020 14:00:00 GMT

Data Obfuscation is Very Real

Anyone who has been involved in any sort of enterprise data migration or integration project can relate to the frustrations associated with trying to get data out of the legacy system. Isn’t this your companies’ data? Why is it then locked away in obscure tables that only the software vendor can decode?

This is an old problem dating back to the initial coding of most PLM systems. In fact, not much has changed in the last 10 years since Aras published “What is PLM Data “Obfuscation” and I Why Should I Care?!?“ The blog cites examples of intentionally obscuring data, such as:

“The database table for the Part Master is not called / labelled “Part” – it’s labelled “0034543908543TG324” or something else confusing like that... the data are sometime split into different tables so that access is non-intuitive. This is “obfuscation” and it’s done by design. PLM systems have traditionally (and still are) very hard to get at the data and figure out, sometimes impossible.”

Fortunately, in the last 10 years customers have learned from previous projects and gotten somewhat savvy. Industry groups like the A&D PLM Action group, and the German initiative “the Code of PLM Openness“came together and demanded certain standards that are aimed at making data interoperable and portable.

Unfortunately, this has not changed the way in which legacy PLM systems are architected. In fact, the problem has become even worse. The problem is no longer just getting one PLM vendor to synchronize with another vendor but, due to mergers and acquisitions, many PLM vendors have ended up with a broad portfolio of data management tools that don’t even interface openly with each other.

In addition, as products have become more complex, it is more important than ever to manage requirements, mechanical data, electrical CAD, as well as software and simulation. While many vendors have a portfolio of products to address each of these needs, those products are not on the same platform. Buying all your software from a single vendor no longer means that those tools will work together.

Purchasing a “suite” of software now means complex and costly integrations with the rest of your enterprise IT ecosystem, but the implementation also requires custom integrations between tools in the suite itself. Since Aras Innovator is a platform rather than a “suite,” these internal integrations do not apply.

If you are wondering how complex the connectivity of a “suite” of software tools can be, look at the various licensing models. Are you paying one price per user for access to everything, or are users locked away from certain data according to their “roles?” Who is defining these roles? Is it your vendor's licensing scheme or is it your company’s admins based on your business needs?

In terms of migrating from one PLM tool to another, “vendor lock-in” is still very real. While all vendors have scrambled to achieve “Open” certifications, none have rearchitected their software to make it easier for users to extract their own data in an easily usable format. (If a PLM vendor requires the purchase of a “Toolkit” for access to their schema, they are not open.)
Fortunately, companies are beginning to ask about data exit strategies at the beginning of the buying journey. While most vendors have committed to the spirit of openness, few were architected to support it.

Before you get into a long-term relationship with a new PLM vendor, pay careful attention to how your company's IP will be handled when the relationship ends. After all, 100% of implementations are eventually replaced—either by migration or upgrade. Buyers are now able to choose how painful that process will be upfront in the buying cycle. Aras’ open APIs and logical schema ensure that YOU are the owner of your data.

Employee Spotlight: Christine Longwell, Product Marketing Manager

Kylie Reardon — Fri, 23 Aug 2019 13:43:00 GMT

Where did you grow up?
Washington, D.C.

What was your first or strangest job?
I was a bartender at a country club through college. When I interviewed for my first internship in college, the hiring manager laughed at that, and I responded, "Where else do you think you can find an engineer who can actually talk to people?" Needless to say I got the job.

What do you like most about your current job?
I love the storytelling aspect of taking technical information and transforming it into something people can understand at a business level. We can make the most amazing software in the world, but if we can't articulate how it solves someone's business problems it won't matter. It is also great to be in a role that follows emerging trends in the technology. I routinely did that when I was working in industry as an engineer, and now it is a part of the job I get paid to do.

What is your greatest accomplishment, work or personal?
The most important role in my life is parenting my 15 year old son and my 13 year old daughter. As a single mom I have tried to teach them to find something they love to do and go after it with conviction. I have worked from home most of their lives, and they are very aware of the commitment it takes to be successful. Everyday is bring your kids to work day and mine are particularly good at being independent and helping me work. It's also nice having minions to make coffee!

Tell us a fun fact about you.
I live in the suburbs, but I am passionate about chickens! I have a coop in the backyard, and a flock of about 6 hens that lay blue, green, peach, and speckled eggs. They aren't very smart, but they have endearing personalities and my neighbors don't mind the fresh eggs..

Pick three words to describe yourself.
Resourceful, Stubborn, Patient

What is one thing on your bucket list?
When my kids have finished school I fully plan to take a sabbatical and sail the Caribbean for 6-9 months. I try to go to the Annapolis Sailboat show every year to keep up on gear and trends. I will look at the new Beneteaus and think in about 8 years I might have one.

What is your favorite quote?
"Reality is merely an illusion, albeit a very persistent one." - Einstein

Do you have any hobbies outside of work?
Too many! I mentioned sailing and my chickens, but I am also a chronic remodeler of both houses and cars. I hike, rock climb, and I'm up for anything outdoors. In my downtime or on airplanes you won't find me without my knitting.

You’re about to perform in a karaoke bar. What song do you pick?
"I Will Survive" - preferably the Cake remix

If you could hang out with anyone for a day, who would it be and why?
Definitely Robert Downy Jr. Aside from being an amazing actor I think it would be great to have a chance to hear how he went from being arrested and imprisoned on multiple drug offenses to being the most successful actor working in Hollywood.

Failure? What Kind of Software Company Thinks Failure Can Be a Good Thing?

Christine Longwell — Wed, 22 Jan 2020 15:00:00 GMT

The cold truth is, all enterprise software implementations fail to a certain extent, and they do so in two fairly predictable ways. Either they miss the mark to some extent during the implementation because the needs have shifted in that time, or changing business requirements require a complete refresh, upgrade, or migration (Oh My!).

If you look at failures as a learning opportunity isn’t it better to fail small? If you were learning to snowboard wouldn’t you want to take some small tumbles rather than run straight down the hardest slope on the mountain?

Fail, Learn, Fix, Repeat

In the first scenario you can’t blame the implementation team entirely. Over the course of an implementation, business needs continue to change, and often customers can’t articulate what they actually need until they have the system configured and then say “Oh… not that.” Inevitably the PLM 2.0 project begins to make usability or functional changes, or even reconfigure the entire data model. By this time, the customizations are mature, the code is rigid, and changes are expensive, time-consuming, and typically over budget.

Agile software implementation is gaining popular support in a lot of forward-looking companies. You can read more on that here. While Agile implementation will get your company closer to the ultimate goal, it absolutely embraces failure. During a sprint the customer can evaluate the added features while they are still young and malleable. This is the epitome of failing early, failing often, and failing cheap. It is also failing forward because the ultimate product is the realization of a changing business goal.

Examine your Mindset!

So why isn’t everyone using Agile deployment? The answer lies in the prevailing mindset that failure is to be avoided at all cost. I had an opportunity to hear Dr. Eve Meceda talk about fixed vs. growth mindsets.

Dr. Meceda describes a spectrum of thought processes ranging from Fixed to Growth mindsets. Traditional project Management follows a very “Fixed Mindset” methodology where you believe you can anticipate and plan for every little activity and variable, and risk. People on the “Growth Mindset” end of the spectrum are more likely to take bold actions, evaluate the outcome, admit failure, and rapidly change trajectory to get on the right path. Growth Mindset leaders admit that they don’t know what they don’t know and are comfortable in that space. They think on their feet, respond to changes rapidly, roll with the punches, and are poised to adopt Agile Methods.

You can fail your way to success!

Agile deployment also goes a long way toward minimizing risk. In his blog, Don’t be a Dinosaur, Mark Reisig talked about various PLM deployments and the risk of finding out massive hurdles late in the project. Migrations are recognized as virtually impossible, technology that looked good at a demonstration turns out to be half baked, and various crucial puzzle pieces just don’t fit together “Out of the Box” as advertised.

There are serious dangers of jumping in blind with both feet only to find the pool is 2 ft deep. While it is dangerous for the company, it is also perilous for the decision makers and their long-term job prospects who choose to throw good money against bad decisions. One glaring example was cited in a recent article by in Engineering.com: “virtually everyone who had some responsibility for the company’s 2016 decision to invest in … the replacement for its old mainframe solution, has resigned, been fired or switched jobs.” Is it worth the risk? Instead of jumping in blindly to find the pool is shallow, why not take the stairs?

When your PLM doesn’t meet your needs any more

The average PLM system is several years old and it’s very likely that your processes have evolved significantly in that time. Your discovering that your PLM simply isn’t working for you anymore. This typically launches a massive project to upgrade your legacy system or migrate to another tool altogether. Rinse and repeat every 5 years or however often your provider releases a new version. Of course, Aras doesn’t ascribe to this methodology.

At the ACE 2019 Conference, John Sperling, SVP of Product Management, discussed releases in Innovator from the previous year as well as our internal shift to an Agile release schedule for Innovator using Scaled Agile Framework (SAFE). Almost a year later we have proven our continuous delivery pipeline launching new functionality to both our core code, and various connector releases available to our users.

It’s understandable that this methodology might be alarming to some people thinking “Oh no! Does that mean I need to constantly do migrations? Ouch!" Well, there are two pieces of good news on that front. First, Aras will perform upgrades for you as part of your subscription. That’s right. It’s included in the cost of your subscription. That means that the implementation and customization can continue through sprints without the massive disruption of moving to the next generation platform and all of the re-coding of customizations that has historically gone with that. The second piece of good news is that our roadmap is public, both past and present, so subscribers can choose when they want to upgrade according to which functionality being released that they want to take advantage of.

Are you ready to be a Resilient Thinker?

In Bruce Bookbinder’s recent blog How Resilient Thinkers are Saving PLM he mentions attributes of successful PLM implementors. They are adaptable, evolvable, and transparent. In addition to the wisdom and experience necessary to run a PLM program, another attribute I would add is that they are bold. They are leaders with the passion and a drive towards excellence, even if that doesn’t go in the right direction 100% of the time. After all, wouldn’t you rather be a little bit wrong while there is still time to fix the issue than get to the end and miss the target entirely?

Failure? What Kind of Software Company Thinks Failure Can Be a Good Thing?

Christine Longwell — Wed, 22 Jan 2020 15:00:00 GMT

Failure? What Kind of Software Company Thinks Failure Can Be a Good Thing?

Christine Longwell — Wed, 22 Jan 2020 15:00:00 GMT

Is your Software Vendor Dictating Your Standards?

Christine Longwell — Tue, 24 Sep 2019 14:00:00 GMT

There is a lot of discussion about Engineering Standards lately. The big question is why? Why would the industry want standardization in software? The obvious answer is interoperability between internal systems and the capacity to synchronize easily with suppliers. From a vendor perspective this would be GREAT! Because they could apply the same techniques to their data integration across the board. What is good for vendors is also good for OEMs because it keeps prices down.

The Myth that Single Vendor Ecosystems are the most Robust

A lot of vendors take the approach that if everyone, vendors included, used their software end to end, the data would flow seamlessly. Ironically, these same vendors sell products with file formats that are incompatible with each other and point solutions that are on different platforms that require complex, custom integrations.

As most PLM providers continue to acquire new companies at an astonishing rate, many customers think “Great, now my electronic design system will work seamlessly with my PLM!” Well… historically it hasn’t really worked that way. The acquisition targets have installed bases that run off the software as it is, and it rarely, if ever, gets rewritten to have a common data model with the other technologies offered in the vendor’s “platform."

The implication is that their solution functions seamlessly out of the box, but it doesn’t really work that way. If they did provide a single unified platform wouldn’t they only have 1 item in their price book?

It Works Out of the Box

As discussed in Mark Reisig’s blog OOTB is Dead:

“According to one PLM vendor, customizing on brittle architecture is a mistake. They recommend using their product OOTB, so just dumb down your processes to fit a tool.”

Are you working for your software, or is your software working for you? Maybe vendor defined “standards” are actually proprietary formats to lock you into their licensing scheme.

Anyone who lived through the ‘80s remembers the VHS vs Betamax (Aka:Beta) wars. If you are post 1980’s, I recommend you catch up on all 3 seasons of Netflix’s Stranger Things.
Sure, Sony came out with the Betamax home recording device in 1975, but few consumers could afford it. Sony was advised that the rest of the industry was standardizing on the lower cost VHS format, but they moved forward with Beta to be first to market. It seems that the vendors who had more open standards and interoperability won out.

Works Across

The key to simple interoperability and easy synchronization, both inside and outside the enterprise, is openness. Some PLM vendors allow you to have some access to portions of their portfolio through partner programs that screen for “strategic alliances”. Non-strategic alliances (vendors who aren’t partners) basically have to hack into the backend of the software to access confusing data tables in an intentionally obscure and undocumented data model that may change between versions.

Aras uses services to enable integrations, so upgrades don’t affect your data model or established integrations. The service-oriented architecture separates the integration process from the core applications on the platform. This eliminates the need for recreating complex coding that is traditionally required to maintain established integrations during the upgrade process.

To make the Digital Thread work, OEMs need to work with different systems internally and externally to pass bidirectional electronic data between systems. Once this interface is developed a one way data exchange weakens the thread. Mutually agreed open interfaces are essential to a true digital thread.

Non-homogeneous Ecosystems

The typical IT ecosystem has more than one system used by various groups. While Aras can’t solve all of those integration problems, we are introducing Data Federation as a core service on our platform. Aras’ Data Federation Services will allow administrators to configure data synchronization data between Aras and other systems without complex custom code. This data can be merged with information from the Innovator data model to enable agreed interfaces between system.

Ultimately, it’s a buying decision.

So, did you develop your standard operating procedures, or did your software vendor inflict “standards” on you? Did you choose the way you work intentionally, or are you working around limitations in your software? Ultimately it is the buyer’s choice to support a vendor who locks away access to your data or to move forward with a platform built for openness and maximum interoperability.

Is PLM a Destination or a Journey?

Christine Longwell — Wed, 19 Jun 2019 15:49:00 GMT

Over the years there have been many celebrations when a PLM system finally hits the “Go Live” point. Champagne is opened, backs are patted, and there can be a general feeling of satisfaction at releasing the product into the organization. Oh, to be young and naive! I have, on occasion, described rolling out a new PLM system as being a bit like giving birth. It’s painful, messy, and quite expensive. Even though you are thrilled to have it you will spend countless sleepless nights trying to make it stop complaining.

While this may mean job security for the PLM consultant role, it raises the question, “Is there a better way?” Having talked to countless PLM customers over the years this can go two ways.

In the first, most common scenario, the functionality missing that makes it possible to achieve business value is planned into “Phase 2.” There is always a phase two! Or three, or four, or they stopped counting because the next big release is going to “fix everything,” which simply restarts the cycle.

The second scenario is certainly more promising. A company will roll out very basic, out of the box functionality with a very limited scope, such as ECOs or document management, in a short time with a small budget. From there, they begin to gather requirements for improvements and analyze those requests according to the required resources and the importance to the business. Whatever is at the top of the list gets incorporated, and a secondary, smaller deployment happens between 2 and 6 weeks later. This continues until the system meets the business needs. Of course, the only constant in business is change, so this could certainly continue as long as a company is focused on continuous improvements.

Waterfall vs. Agile

Seasoned veterans of Enterprise software deployment already know that the two scenarios above represent the difference between Waterfall and Agile project management methodologies. Waterfall projects have dominated the Project Management best practices according to the PMI (Project Management Institute) for a very long time, and with good reason. Many contracts are specifically written AFTER the requirements phase has been documented, and the client wants to know precisely what they are getting and when.

The problem is, you simply don’t know what you don’t know. In the time it takes to deliver on the promised scope two things always becomes apparent. One, someone forgot something, which leads to the dreaded “scope creep” or “change orders” that cause the project to cost more money and take more time than originally planned. Secondly, the business changes. Mergers and acquisitions take place, disruptive technology is introduced to the market, customer demand shifts, global macroeconomic conditions change, regulations are introduced that require compliance, new management enters the project, a newer version of the software is introduced, or a variety of other changes happen. The probability of change happening over the course of a waterfall project far outweighs the probability of conditions remaining the same.

In the second scenario, commonly recognized as Agile Methodology, all of the same steps are followed. However, the Gather Requirements, Design, Develop, Test, and Deploy steps happen much more quickly. Where a traditional Waterfall project can easily take 2-3 years to reach the “Go Live” date, a typical agile cycle (called a “Sprint”) happens every 3-6 weeks, depending on the development team. An Agile team, along with their executive sponsor, begins with a Minimally Viable Product (MVP), and customizes the solution from there.

What you Need for Iterative Deployment

Assuming a company decides to roll out their PLM using an Agile deployment methodology, the question needs to be asked, how easy is it to deploy the software, and does a deployment wipe out former customizations to the environment? Many traditional systems simply overwrite themselves every time a customization is made since the entire environment needs to be redeployed. Not only does this discourage the release of an MVP, but it forces changes to be “lumped” into service packs that are deployed as infrequently as possible.

The Aras platform is different in that it is built for change. Customizations are easy to make, the platform is flexible and robust, and the client machines never need updating. A change cycle, or “Sprint” in Aras involves a basic Export, Test, and Import to the production environment without reinstalling any underlying software. In other words, there is no “redeployment” required.

One of Aras’ key differentiators is that upgrades to the latest software are included as part of the subscription. This ensures that customizations will not be wiped out as the platform moves to another version. Many PLM systems require massive internal effort around upgrade planning, execution, and data reassurance which makes all of the technical team unavailable to focus on continuous improvement. With Aras the Agile deployment team is free to build and deploy whatever the business needs on a platform designed to grow and scale without concerns of upcoming upgrades.

Plays Well With Others

Another core requirement for iterative deployment is the ability to quickly and easily integrate with the incumbent data tools inside of the functional IT ecosystem. When a company plans to change those tools, a system with an open and transparent API will enable sustainable digital transformation without disrupting crucial functionality. Aras has openness and flexibility at our core, and we are very well regarded for working with other systems through Data Federation, on top of our open API, in order to complement, extend, and replace existing systems.

In Conclusion

To use an analogy, the waterfall method is like following a recipe and serving a meal without tasting it along the way. That might work at a restaurant with consistent, repeatable recipes but the average person will taste the pasta to see if it is done, add pepper to taste, and make decisions about the process that will change the outcome of a meal according to their best decisions in the moment.
And finally, what good would it be to make a recipe only once? Using the agile approach home chefs everywhere can learn from what worked and what didn’t, incorporate additional ingredients, alter the proportions, and eventually make the meal taste better each time with less effort. The next time you try a new recipe consider that you are working from lessons learned on a “previous sprint” to continually improve your dish and come one step closer to culinary perfection.

Christine Longwell さんの グループ アクティビティ

Agile Supports Faster Upgrades

Do you Love Your PLM?

Do you Love Your PLM?

Nice Blog!

Rectifying the Bill of Materials with the Bill of Process: A Story of Nouns and Verbs

The Myth of the Magical Data Lake

The Myth of the Magical Data Lake

A Platform Recipe for Success

Whose Data Is It Anyway?

Employee Spotlight: Christine Longwell, Product Marketing Manager

Failure? What Kind of Software Company Thinks Failure Can Be a Good Thing?

Failure? What Kind of Software Company Thinks Failure Can Be a Good Thing?

Failure? What Kind of Software Company Thinks Failure Can Be a Good Thing?

Is your Software Vendor Dictating Your Standards?

Is PLM a Destination or a Journey?

Waterfall vs. Agile

What you Need for Iterative Deployment

Plays Well With Others

In Conclusion

Christine Longwell さんのグループアクティビティ