How Simon connected engineering and manufacturing across four continents with ISFsoft Viewer
Simon designs and manufactures electrical switches, sockets, lighting, and connectivity solutions for markets across the globe. With over 200 engineers based in Barcelona and China, and manufacturing plants operating in Brazil, Mexico, India, and Poland, the company runs a genuinely international product development operation. A decision made in Barcelona has direct consequences on a factory floor thousands of kilometres away.
Keeping engineering and manufacturing aligned at that scale is not a given. It requires more than a good PLM system. It requires that the people who need engineering data can actually get to it, reliably, and without depending on someone else to retrieve it for them.
That was the problem Simon needed to solve.
The situation before Viewer
Simon's engineering team works in PTC Windchill. Their product data, assemblies, components, drawings and specifications, is structured, versioned, and controlled inside the PLM environment. But Windchill access was limited to the engineering team. Manufacturing teams at international sites had no direct, reliable way to consult that data.
The result was a gap between what engineering knew and what manufacturing could act on. Errors were surfacing too late, at the manufacturing phase, when the cost of fixing them is significantly higher than catching them upstream. An initial attempt to bridge this with PTC Navigate View licenses proved difficult to scale across a geographically distributed organization with multiple sites, each with its own operational reality.
Something more flexible was needed.
The solution: ISFsoft Viewer as the access layer
ISFsoft Viewer was implemented in combination with PTC Navigate View, providing a dedicated visualization server that makes Windchill data accessible to non-engineering teams, without requiring PLM licenses or expertise.
A Windchill workflow was configured to publish data automatically to the Viewer server, distributing up-to-date engineering information from Barcelona to manufacturing plants in Brazil, Mexico, India, and Poland. The moment engineering updates something in Windchill, that change becomes available to every site through Viewer.
The rollout was gradual and site-driven. Rather than imposing a uniform change across four countries at once, each manufacturing plant defined its own adoption timeline and product strategy. This meant the implementation could flex around operational realities, reducing friction and accelerating actual adoption on the ground.
The results across 150 users
With ISFsoft Viewer in place, manufacturing teams at every site now have direct access to current engineering data. The impact has been visible across several dimensions.
Error discovery moved upstream. Manufacturing teams can now identify issues before they reach the production floor, reducing the cost and disruption of rework. The engineering team, no longer fielding data access requests from across four time zones, recovered significant capacity.
And for the first time, every site, Barcelona, Brazil, Mexico, India, Poland, is working from the same version of the truth.
But the most significant outcome may be structural. With Viewer providing a reliable, shared view of engineering data across the organization, Simon had the foundation it needed to go further: moving from folder-based project management to a structured, Windchill-based PLM approach. Viewer was not just a fix for the access problem. It was the trigger for a broader shift in how Simon manages its product data at a global level.
A bridge that scales
What the Simon implementation illustrates is a pattern that applies across manufacturing organizations of similar complexity: the value of a PLM system is not just in the data it holds, but in how accessible that data is to the people who need to act on it.
ISFsoft Viewer connects to Windchill and exposes the relevant data, assemblies, components, drawings and attributes, through an interface that manufacturing, quality, procurement, and other teams can use without training, without licenses, and without creating risk to the PLM environment. For multi-site organizations, it also solves the synchronization problem by design: one source, one published view, always current.
Does your manufacturing team have direct access to Windchill data?
If your engineering team is the gatekeeper of data that manufacturing, quality, or procurement need to do their work, ISFsoft Viewer is designed to change that, without disrupting your existing PLM environment.
Explore ISFsoft Viewer →
More real-world examples
Simon is one of several manufacturing companies that have transformed the way they connect engineering and production with ISFsoft. Explore more case studies to see how other teams are getting more out of their Windchill investment.
Explore all case studies →
If your Windchill and ERP are "connected" by Excel files, you don't have an integration, you have a workaround
Most manufacturing companies running Windchill will tell you they already have some kind of connection with their ERP. And technically, they are right. Data moves between the two systems. BOMs get transferred. Item lists are updated. Engineering changes eventually make their way into production.
The question is how.
In the vast majority of small and mid-sized industrial companies, the answer is the same: someone exports data from Windchill into a spreadsheet, works on it, and uploads it into the ERP. Or the other way around. Sometimes with a bit of scripting on top. Sometimes entirely by hand.
That is not an integration. That is a workaround that has become invisible because everyone has learned to live with it.
How spreadsheet-based transfers become the standard
This is not a criticism of the people who set it up. When a company first implements Windchill and an ERP, a full real-time integration is rarely the priority. There is a go-live deadline, a limited budget, and a team that needs to start working. Someone figures out a process using export files, it works well enough, and it becomes the de facto method.
Years later, that same process is still running. It has been documented, it has been handed from one person to the next, and it has become so embedded in daily operations that nobody questions it anymore. It is just how things work here.
The problem is not the spreadsheet itself. The problem is what happens when the business grows, the product catalogue expands, the pace of engineering changes accelerates, and the volume of data that needs to move between systems increases. What was manageable at fifty items becomes a liability at five hundred.
The real cost of moving data through files
Spreadsheet-based transfers between Windchill and ERP create a specific set of problems that rarely show up in a single dramatic failure. They accumulate quietly, in the background, until they become impossible to ignore.
Version mismatches
By the time a file is exported, processed, reviewed and imported into the ERP, the source data in Windchill may have already changed. Engineering revisions move faster than manual transfer cycles. Production ends up working from a BOM that is one or two iterations behind the current design — and in many cases, nobody knows until something goes wrong on the shop floor.
Human error at every step
Every manual intervention in the transfer process is a potential point of failure. A column mapped incorrectly. A row accidentally deleted. A filter applied to the wrong field. These are not exceptional events. They are routine, and they have routine consequences: rework, incorrect procurement orders, and inventory built around obsolete configurations.
Dependency on specific people
In most companies using this model, the transfer process is only fully understood by one or two individuals. When those people are unavailable — on holiday, sick, or simply gone — the process slows down or stops entirely. The organization has built a critical operational dependency around a manual routine.
No traceability
When data moves through a spreadsheet, the audit trail disappears. If a BOM error is discovered three months later, tracing it back to a specific file version, a specific transfer, or a specific decision is extremely difficult. For companies operating in regulated industries or with strict quality requirements, this is not just an inconvenience — it is a compliance risk.
The time nobody accounts for
Someone has to prepare the file, validate it, send it, confirm receipt, and troubleshoot when something does not match. This work does not show up in any integration budget because it is absorbed by the team as part of their normal workload. But it represents real hours, every week, spent on data logistics instead of engineering or operations.
Spreadsheet-based transfer vs. real-time integration with ISFsoft Connect
When the workaround stops working
There are usually clear signals that the spreadsheet transfer model has reached its limit, even if they are not immediately recognized as integration problems.
Engineering change cycles slow down because the effort required to push changes through to ERP creates a bottleneck. Product launches take longer than they should because teams spend days reconciling data before anyone can commit to a manufacturing plan. Quality incidents increase and trace back to BOM inconsistencies between what engineering defined and what production received. And the people managing the transfer process start spending more and more time on it, with less and less time for anything else.
At this point, the question is no longer whether to improve the integration. The question is how long the organization can afford to wait.
What a real integration between Windchill and ERP looks like
A proper integration does not mean replacing the spreadsheet with a more sophisticated spreadsheet. It means eliminating the manual transfer step entirely.
When Windchill and ERP are connected through a dedicated integration layer, product data flows automatically and in a controlled way. New items created in Windchill are reflected in ERP without manual intervention. BOM structures and revisions are synchronized as soon as they are released. Engineering Change Notices trigger the corresponding updates in ERP in real time. And every transaction is logged, traceable and auditable.
The operational impact is significant. Version mismatches disappear because there is no delay between the source data and the downstream system. Errors caused by manual handling are eliminated. The people who were managing the transfer process are freed to do higher-value work. And the organization gains a level of operational confidence in its data that simply does not exist when spreadsheets are in the middle.
ISFsoft Connect: built for Windchill environments
ISFsoft Connect is an integration platform designed specifically to connect Windchill PLM with ERP systems. It works as an Enterprise Service Bus, managing the synchronization of product data, engineering structures and operational information between both platforms in a controlled, bidirectional and traceable way.
The processes it supports cover the full scope of what companies currently manage through manual transfers: item creation and updates, BOM synchronization, Engineering Change Notice and ECO flows, manufacturing process plans, and option and variant expressions. All of it automated. All of it logged.
ISFsoft Connect also handles the heterogeneity that is typical in real industrial environments — different ERP systems, different data formats, different protocols — without requiring companies to standardize their entire technology stack first.
The result is an integration that does not depend on a spreadsheet, does not depend on a specific person, and does not introduce a manual step between what engineering defines and what operations receives.
If your Windchill–ERP connection currently runs through files, that is where to start.
Learn more about ISFsoft Connect and how it replaces manual data transfers with a real integration between Windchill and ERP ››
How Figueras Seating eliminated manual data management in Windchill without changing their PLM
There is a situation that many Windchill environments share, even in companies that have invested heavily in PLM: the system holds the data, but people are still doing the work of moving it.
Every new project triggers a wave of manual tasks. Items created one by one. BOMs copied and adjusted by hand. Files sent to suppliers without any guarantee they are the right version. And underneath it all, a Windchill environment quietly filling up with outdated and duplicated content that no one has time to clean.
This is not a technology problem in the sense that Windchill is broken. It is a workflow problem — and it tends to go unnoticed precisely because teams adapt to it. They build routines around the gaps. Until the volume grows too large, or a mistake costs too much, or someone stops to calculate how many engineering hours are spent on data management instead of engineering.
Figueras Seating reached that point.
A precision business with a manual data problem
Figueras designs and manufactures premium seating for auditoriums, theatres, cinemas, and stadiums in more than 150 countries. Every installation is different: seat dimensions, curvature, positioning, and finish are all defined by the specific geometry of each venue. There is no off-the-shelf configuration — each project is a custom engineering exercise.
That level of customization generates a high volume of items, versions, and CAD documents. And for every project, that data had to be loaded manually into their ERP system (Microsoft Navision), with no automated connection between PLM and ERP.
The consequences were predictable, though no less costly for being so.
The four problems that were costing the most
1. Loading project data into Windchill and ERP was slow, manual, and error-prone
Each new project meant creating and updating items one by one across both systems. With complex, customized BOMs — where every seat in a venue can have its own configuration — the volume of manual input was significant. And manual input means inconsistencies: data that does not match between systems, items created with errors, versions that diverge.
The time cost was real. So was the risk. In a business where every installation is unique and tolerances are tight, a data error does not stay in a spreadsheet — it travels downstream into production.
2. Windchill was accumulating noise it could not clean itself
Without an automated and controlled flow for creating and updating items, obsolete and duplicated content builds up over time. Items that were replaced but never removed. Versions that should have been superseded but were not. A PLM environment that was meant to be the single source of truth was instead becoming a source of uncertainty.
Cleaning this manually is time-consuming and disruptive. Most teams deprioritize it. The noise grows.
3. Errors in data became errors in production
When the connection between engineering data and manufacturing is handled by people rather than systems, the margin for error is wide. An outdated BOM reaching the shop floor. A component specified incorrectly because the item in ERP did not reflect the latest version in Windchill. Rework, delays, costs that should not have been there.
In high-precision, high-customization manufacturing, the cost of a data error is not just the error itself — it is everything that flows from it before anyone catches it.
4. Suppliers and partners were working without version certainty
Distributing project documentation to external partners — suppliers, subcontractors, site teams — was done without a controlled mechanism to ensure they always received the correct, current files. 2D drawings and 3D models sent outside Windchill lose their connection to the source. Someone builds from a drawing that has since been updated, and no one necessarily knows until it becomes a problem on site.
What changed with Windchill Utilities
Two applications from the Windchill Utilities suite addressed these problems directly.
Bulk Creation & Update Tools introduced an automated, Excel-driven interface between Windchill and Navision. Instead of creating and updating items manually in each system, the team now manages data through a structured process that keeps both platforms consistent. The Windchill mBOM and the ERP BOM for each project stay aligned, without manual synchronization.
Download Baseline Components gave the team a controlled mechanism for distributing project documentation externally. Files — primary content, attachments, and object representations — are grouped into structured baselines directly from Windchill, ensuring that suppliers and partners always receive the correct version of 2D and 3D files. Windchill remains the single, authoritative source.
The results
- Manual input eliminated across complex, customized BOMs — significantly reducing both time and errors when loading project data.
- Obsolete and duplicated items no longer accumulate, removing the overhead of periodic cleanup and restoring confidence in the PLM environment.
- Fewer errors reaching production, with a direct impact on rework costs, delivery speed, and product quality.
- Suppliers and partners always receive the correct, up-to-date file versions — distributed directly from Windchill baselines.
- A stable, maintainable environment that can evolve alongside both Windchill and ERP without accumulating technical debt.
Is your team spending engineering hours on data management?
If any of the situations above feel familiar, the gap is likely not in your PLM platform — it is in the workflow connecting it to the rest of your operation.
Windchill Utilities by ISFsoft is a suite of productivity applications designed to automate routine tasks, eliminate manual data management, and keep your Windchill environment clean, consistent, and ready to scale.
Explore Windchill Utilities →
See how other manufacturers are working smarter with Windchill
Figueras is not the only company that has transformed the way it manages engineering data. Explore more real-world examples of how ISFsoft helps manufacturing teams eliminate inefficiencies, connect their systems, and get more out of their PLM investment.
Explore all case studies →
Why your sales team shouldn't depend on engineering to make a quote
The scene you know too well
It's Tuesday afternoon. A promising lead has asked for a quote on a customized machine. Your sales rep pulls together the commercial details — pricing, delivery terms, margin — but before anything can go out, they need engineering to validate the configuration.
Engineering is already deep in three active projects. They'll get to it by Thursday. Maybe Friday.
The customer follows up on Wednesday. The sales rep says "we're working on it." On Friday the quote goes out. By Monday, the customer has signed with a competitor who replied on Wednesday.
Sound familiar? For most industrial manufacturers — especially those working in Engineer-to-Order (ETO) or Configure-to-Order (CTO) environments, this isn't an edge case. It's the default.
Why this happens: the knowledge problem
The core issue isn't speed or workload. It's where product knowledge lives.
In most manufacturing companies, the rules that govern how a product can be configured — which components are compatible, what's technically feasible, how a change in one module affects another — exist exclusively inside the heads of engineers and in the structure of your PLM system.
Sales teams don't have access to that knowledge in any usable form. So every time a customer asks for something even slightly customized, the commercial process hits a wall and waits for the technical team to climb over it.
This creates a structural dependency that's slow by design. Not because your engineers are slow — they're not — but because they're being used as a lookup service for information that shouldn't require their expertise to retrieve.
The real cost: further than you think
The obvious cost is the delayed quote. But the downstream effects are harder to measure and far more damaging.
Lost deals you never see. Many customers don't tell you they went elsewhere. They simply go quiet. You follow up, they politely say they went in a different direction. You never know that a 48-hour delay was the reason.
Engineering time destroyed. Every interruption to validate a configuration or check feasibility for a quote that may never close pulls an engineer out of design work. Studies on context-switching in technical roles consistently show that a five-minute interruption can cost 20 minutes of productive work. Multiply that across a week and you're looking at significant capacity loss.
An unreliable customer experience. Today's industrial buyers have rising expectations about responsiveness. If your process feels slow and opaque compared to what they experience in their personal lives or with more agile competitors, it erodes trust before the relationship even begins.
A sales team that feels powerless. Experienced sales reps know this pain well. Over time, it changes how they work: they stop pursuing edge cases, they self-censor ambitious customizations, they promise less to avoid the engineering bottleneck. The commercial potential of your product portfolio shrinks, quietly, from the inside.
This is worth reading carefully if your sales cycle for complex products regularly exceeds a week. The bottleneck described here is solvable and solving it doesn't require hiring more engineers.
It's not a people problem
Before going further, it's worth being explicit about something: the friction described above is not caused by engineers being uncooperative, or sales being impatient.
It's a process and tooling problem.
The current workflow asks the wrong people to do the wrong jobs. It uses your highest-cost technical resources to answer questions that — with the right system — shouldn't require human judgment at all. And it leaves your commercial team without the autonomy they need to compete effectively.
Reframing it this way matters because the solution isn't cultural (telling engineering to be faster) or organizational (hiring more engineers). It's structural: give the right people access to the right product knowledge, at the right moment in the process.
What CPQ means in a complex manufacturing context
CPQ stands for Configure, Price, Quote. In consumer contexts it often refers to simple product builders. In industrial manufacturing, particularly ETO and CTO environments, it means something considerably more demanding.
A CPQ solution for complex manufacturing needs to:
- Encode the full logic of your product variants, constraints, and dependencies
- Allow a non-technical user to configure a valid, technically feasible product
- Automatically generate an accurate price based on the selected configuration
- Produce a quotation document that can go straight to the customer
- Optionally, trigger downstream outputs like eBOMs, 3D drawings, or production documentation
The key word in that list is valid. The system must prevent invalid configurations from being created in the first place — not flag them after the fact. That's the difference between a tool that creates work and one that eliminates it.
For companies running their product data in PTC Windchill, this presents a specific challenge: the CPQ solution needs to integrate natively with the Windchill environment, drawing on the product structures, part libraries, and variant logic already defined there — not replicate or duplicate them.
What changes when sales can configure independently
Here's the before/after at a workflow level:
Before: Customer request → Sales collects details → Sales contacts engineering → Engineering reviews and validates → Engineering approves or suggests changes → Sales produces quote → Customer receives quote. Typical elapsed time: 3–7 business days.
After: Customer request → Sales opens configurator → Sales builds valid configuration using guided logic → Price is calculated automatically → Quote is generated in minutes → Customer receives quote. Typical elapsed time: same day.
Engineering is not removed from the process. They define the configuration logic upfront — the rules, constraints, and pricing models. That's one-time, high-value work. What they're freed from is being consulted on every individual quote
ISFsoft Sales Configurator is built specifically for this workflow: a CPQ solution designed for PTC Windchill environments, with native support for ETO and CTO processes. It allows sales teams to independently generate complete, technically valid quotes for complex customized products — without opening a support ticket with engineering.
What to look for in a CPQ for ETO/CTO environments
If you're evaluating CPQ options for a complex manufacturing context, these are the criteria that separate a useful solution from one that creates more problems than it solves:
Native PLM integration. The configurator should read product logic from your existing PLM — not require you to maintain a parallel dataset. In a Windchill environment, this means bi-directional integration, not just an export.
Constraint-based configuration. Rules that prevent invalid combinations must be enforced at the point of selection, not surfaced as errors after the fact.
Automatic eBOM and drawing generation. For the quote to be more than a commercial document, it should trigger the technical outputs engineering needs: structured BOM, updated CAD drawings, production-ready documentation.
Role-appropriate interface. Sales users shouldn't need to understand product architecture. The interface should guide, constrain, and present options in commercial terms.
Scalability across product complexity. Solutions that work for 10 variants often break at 1,000. Verify it against your actual product catalog, including your most complex configurations.
The deeper shift: from gatekeeping to enabling
The most durable benefit of giving sales teams configurator autonomy isn't the faster quote. It's the change in how your organization relates to its own product knowledge.
When configuration logic is encoded in a system — rather than locked in engineering heads — it becomes shareable, scalable, and consistent. A new sales hire can quote as accurately as a 10-year veteran on day one. A partner or distributor can configure products without calling your office. The commercial surface of your company expands without proportional headcount growth.
That's not a small thing in an industry where product complexity tends to grow faster than the teams managing it.
See it in action
ISFsoft Sales Configurator is designed for manufacturers running PTC Windchill who want to close the gap between sales and engineering — without losing technical accuracy or forcing expensive customization.
Explore ISFsoft Sales Configurator →
Or if you'd like to see how it handles your specific product configuration challenges:
Talk to our team →
ISFsoft is developed by ISF Innovation Experts, an official PTC technology partner. The ISFsoft suite extends PTC Windchill with purpose-built solutions for visualization, integration, spare parts management, and product configuration.
The invisible bottleneck in Windchill environments: why engineering becomes the gatekeeper of data
Every manufacturing company that has invested in PTC Windchill knows the promise: a single source of truth for all engineering data. BOMs, CAD models, technical documentation, part revisions — all controlled, versioned, and reliable.
And yet, in most of these organizations, something quietly goes wrong. Not in the system itself, but around it.
The problem nobody talks about in PLM reviews
Ask any engineer in a Windchill-enabled company what their day looks like, and you will hear a version of the same story. Between design reviews, change requests, and validation tasks, there are the interruptions: a call from purchasing asking for the latest BOM of a component, an email from sales needing a 3D model for a customer presentation, a message from production asking whether drawing REV C or REV D is the one currently approved for manufacturing.
These requests are reasonable. The data exists. Windchill has it. But accessing it requires credentials, training, licenses, and a level of technical fluency that most people outside engineering simply do not have.
So the request lands on an engineer's desk. Then another one. Then ten more.
This is the invisible bottleneck and it is costing organizations far more than they realize.
When the system works, but the organization doesn't
Windchill is designed for engineering and PLM teams. Its data model, navigation logic, and permission structures reflect that. It is powerful precisely because it handles complexity: lifecycle states, variant configurations, associativity between CAD models and drawings, multi-level assemblies.
But that same sophistication creates a barrier for everyone else.
The procurement manager who needs to verify a part number. The after-sales technician looking for the exploded view of an assembly. The product manager preparing a roadmap presentation. The quality engineer in a supplier audit. None of them need the full power of Windchill. They need one specific piece of information, quickly, without a learning curve.
When that access doesn't exist, two things happen. First, those people stop trying to go to the source and start relying on informal channels — outdated PDFs saved on shared drives, screenshots shared on messaging platforms, verbal confirmations that may or may not reflect the current revision. Second, engineers absorb the demand, spending increasing portions of their workday as data intermediaries rather than doing the work they were hired to do.
The compounding costs of a data silo
The consequences are not just a matter of lost engineering hours, though that alone is significant. The downstream effects compound across the organization.
Part proliferation becomes a persistent problem when purchasing and production teams cannot easily search existing components before requesting new ones. Engineers approve variants that already exist in the system, simply because nobody checked.
Rework escalates when production or quality teams work from documentation that is not the latest approved revision. A drawing updated in Windchill two weeks ago may still be printed and laminated on the factory floor.
Decision-making slows down at every level. Product reviews, supplier negotiations, change impact assessments — all of them depend on people having access to reliable, current data. When that access requires submitting a request and waiting for an engineer to respond, velocity suffers.
Innovation stalls because the people responsible for it are busy answering data requests instead of solving engineering problems.
The root cause: access was designed for experts
This situation is not the result of poor PLM implementation. Most Windchill deployments are technically sound. The root cause is an assumption embedded in how enterprise PLM tools have traditionally been conceived: that the people who manage data are the same people who consume it.
In practice, that is never the case. The data lives in engineering, but the need for that data spreads across the entire organization and often beyond it, to suppliers, integrators, and service partners.
Designing access around expert users means that everyone else is excluded by default. And in organizations where data literacy and engineering expertise are not evenly distributed, which is every organization, exclusion becomes a structural bottleneck.
What democratizing access actually means
The phrase "data democratization" is used often enough to have lost some of its meaning. In the context of Windchill environments, it means something specific: giving every person in the organization the ability to find, view, and use the engineering data they need, without relying on an engineer to retrieve it for them.
This is not about opening up editing rights or removing governance. The integrity of Windchill data — its revision control, its lifecycle states, its approval workflows — must remain intact. What changes is the layer through which non-engineering users interact with it.
A read-only, intuitive, web-based interface that surfaces the right information in a form that any user can understand without PLM training is not a replacement for Windchill. It is an extension of it — one that absorbs the demand currently falling on engineering teams and redirects it to a self-service model.
What changes when the bottleneck is removed
When non-engineering teams can access data directly and independently, the shift is felt across the organization almost immediately.
Engineers reclaim time. Not in small increments, but in meaningful blocks that can be redirected toward the work that actually drives value: design, optimization, problem-solving.
Cross-functional teams move faster. Product development cycles that previously required multiple handoffs to retrieve information become more fluid. Departments that were data consumers become data-empowered.
Decision quality improves. When the product manager, the sales engineer, and the procurement lead are all looking at the same current, approved data, not a copy, not a screenshot, not a memory, the risk of decisions being made on outdated or incorrect information is substantially reduced.
And the cultural dynamic shifts as well. Engineering stops being the department that others are waiting on for basic information, and starts being the department that others trust as the source of truth, because access to that truth is no longer a bottleneck.
ISFsoft Viewer: built for this specific problem
ISFsoft Viewer was developed precisely to address this gap. It provides a web-based interface that connects to PTC Windchill and makes engineering data accessible to any user in the organization, without requiring Windchill licenses, without PLM training, and without involving engineering teams in the retrieval process.
Users can search by part number or name, browse structures, visualize 2D drawings and 3D models with zoom and rotation, download approved documentation, and access metadata, all from a clean, intuitive interface that works in any browser, on any device, 24 hours a day.
Access is controlled through role-based permissions, so each user sees exactly what they are authorized to see. The data always reflects what is current and approved in Windchill. There are no copies, no synchronization delays, no risk of working from an outdated version.
Equally important, ISFsoft Viewer is designed to be accessible from a cost perspective. Unlike solutions that charge per user, it operates on a server license model, meaning the entire organization can benefit from it without the licensing costs scaling with headcount. Broad adoption, which is precisely the point, does not come with a proportionally large bill.
For organizations running Windchill, it is not a replacement or a workaround. It is the access layer that was always missing.
Want to see how ISFsoft Viewer works in a real Windchill environment? Request a demo and explore what your teams could access today.
Windchill custom development vs independent software: a strategic choice for PTC partners
When “extension” becomes a risk
In the PTC ecosystem, terms like “extensions”, “add-ons”, “plugins”, “integrations” and “custom code” are often used as if they meant the same thing. For Windchill partners, that confusion is not harmless: it directly affects project scope, delivery expectations, and who carries the long-term responsibility once the system is live.
When customers ask for capabilities beyond standard Windchill functionality, many conversations jump straight to custom development. Sometimes that is the right answer. The problem is when it becomes the default, especially for needs that repeat across customers. That is how partners quietly accumulate technical debt, rising maintenance costs, and increasing delivery risk, often without pricing those commitments properly.
What “independent software” means in a Windchill context
Independent software designed to work with Windchill is not “Windchill code”. It is a separate product with its own lifecycle, built to integrate with Windchill, leverage Windchill data, and extend functional coverage around the platform, while remaining a standalone solution.
That distinction matters because it changes the nature of the promise a partner makes. With productized software, the partner introduces a capability that is versioned, documented, supported, and improved through a vendor roadmap. With custom code, the partner often becomes the long-term owner of the solution’s evolution, compatibility, and stability.
In mature PLM environments, where similar requirements appear again and again, independent products can provide a scalable way to deliver outcomes without turning every request into a new permanent engineering obligation.
Why custom development becomes expensive after go-live
Custom work is attractive because it feels flexible and immediate. It can also generate short-term services revenue. The long-term cost, however, usually shows up after go-live: upgrades, regression testing, unexpected interactions with other systems, staff turnover, and the reality that “small” customizations are rarely small two years later.
The issue is not that custom development is bad. The issue is that recurring needs solved with repeated custom builds create complexity that does not scale. Over time, teams end up maintaining multiple variants of similar functionality across customers, which increases effort and erodes margins. In practice, partners pay for this with time, delivery capacity, and predictability.
The strategic difference: repeatability and controlled risk
The real advantage of independent software is not technical elegance; it is business scalability. PTC partners that grow profitably tend to build portfolios of repeatable offerings, using custom work selectively, only where it is truly unique.
Productized capabilities are easier to position, scope, and package. They reduce uncertainty in proposals, shorten delivery cycles, and lower the risk that a project becomes hostage to a bespoke codebase. They also make the partner’s model more resilient, because value scales through repeatability rather than through increasing complexity.
A partner decision, not just an engineering choice
Ultimately, the choice between independent software and custom development is a decision about what kind of partner business you want to build. If growth depends on one-off builds, the business scales with complexity and internal bottlenecks. If growth depends on repeatable capabilities around Windchill, the business scales with controlled risk and predictable delivery.
Custom development will always have a place. But treating it as the default for recurring requirements is rarely sustainable. In a competitive Windchill market, clarity on this point is not a technical nuance, it is a strategic advantage.
If you are a Windchill partner looking to expand your offering with repeatable, lower-risk capabilities, we’d be happy to talk about partnering >>
The hidden cost of disconnected Windchill PLM and ERP systems in manufacturing
Digital transformation in manufacturing often begins with the implementation of powerful platforms such as Windchill PLM and a robust ERP system. On paper, the technological landscape looks complete: engineering manages product structures and revisions in Windchill PLM, while operations, procurement and finance rely on ERP to plan and execute production.
However, in many industrial organizations these systems do not truly operate as one.
When Windchill PLM and ERP are not properly integrated, the gap between engineering and operations quickly becomes a structural weakness. What initially appears to be a technical limitation gradually turns into an operational problem that affects cost control, product quality and time-to-market.
The operational risk of disconnected systems
Modern product development is significantly more complex than it was just a decade ago. Companies design products that combine mechanical components, electronics and software while coordinating engineering teams, suppliers and manufacturing sites across multiple locations and time zones.
In this context, product information cannot remain isolated inside engineering tools.
When Windchill PLM operates independently from ERP, the organization begins to fragment. Engineering defines product structures and revisions in Windchill PLM that production may not immediately see reflected in ERP, while manufacturing teams update operational data that rarely flows back into engineering environments. Procurement and finance may therefore work with cost or planning data that does not fully match the latest design reality.
The result is not immediate chaos, but a gradual accumulation of inefficiencies. Manual exports, spreadsheet bridges, duplicated data entries and email confirmations become routine practices that compensate for the lack of system synchronization.
Over time, these workarounds create a fragile operational model that slows the organization down.
BOM inconsistencies: the most visible symptom
One of the areas most affected by the lack of integration between Windchill PLM and ERP is the Bill of Materials. The BOM represents the backbone of manufacturing operations, connecting engineering design with procurement, planning and production.
When BOM structures or revisions must be transferred manually between Windchill PLM and ERP, inconsistencies inevitably appear. A component revision may be outdated, a variant configuration may be incomplete, or a manufacturing process may not reflect the most recent engineering change.
These inconsistencies quickly move beyond the system and into the shop floor. Production errors increase, rework becomes more frequent and inventory levels grow unnecessarily because outdated or incorrect data drives operational decisions.
What initially appears to be a minor data synchronization issue can therefore translate into measurable financial impact and operational inefficiency.
Engineering changes without synchronization
Engineering Change Notices and Engineering Change Orders are essential for controlling product evolution. Windchill PLM provides the structure and traceability needed to manage these changes, but the benefits disappear if the changes are not automatically synchronized with ERP.
Without integration, production may continue manufacturing based on obsolete revisions while procurement orders components tied to previous versions of the product. Project schedules may also fail to reflect the real impact of engineering modifications.
In global manufacturing environments where production operates continuously, this lack of synchronization increases operational risk and complicates compliance and traceability requirements.
More importantly, it undermines confidence in enterprise data. When teams cannot fully trust the information available in their systems, decision-making slows down and additional validation steps become necessary before moving forward.
The hidden impact on time-to-market
Many organizations believe their time-to-market challenges come from product complexity or limited resources. In reality, the underlying problem is often data inconsistency between Windchill PLM and ERP.
Before launching a product, teams frequently spend significant time verifying that engineering data and manufacturing structures match across systems. They review BOM revisions, validate routing information and manually reconcile discrepancies that appear between platforms.
These activities do not contribute to innovation or product improvement. Instead, they compensate for disconnected systems.
When Windchill PLM and ERP are properly integrated, synchronization becomes automatic and the number of data errors decreases significantly. As a result, product launches move faster because teams can focus on engineering and manufacturing decisions instead of resolving system inconsistencies.
Integration as a strategic capability
Integrating Windchill PLM with ERP is not simply a technical improvement but a fundamental step toward operational coherence. When engineering, manufacturing and business systems are properly connected, product information flows consistently across the organization and teams can rely on a single source of truth.
This alignment allows companies to reduce errors, improve collaboration and accelerate decision-making while maintaining full traceability of product and manufacturing data.
In modern manufacturing environments where complexity continues to grow, the integration between Windchill PLM and ERP has become a critical capability rather than an optional improvement. Organizations that succeed in connecting these systems are not only improving their IT architecture; they are strengthening the foundation that supports their entire product lifecycle and operational performance.
This is precisely the role of ISFsoft Connect. Designed as an integration platform between Windchill PLM and ERP systems, ISFsoft Connect enables organizations to synchronize product data, engineering changes, manufacturing structures and operational information across systems in a controlled and traceable way. By creating a reliable bridge between engineering and operations, companies can eliminate manual data transfers, reduce inconsistencies and ensure that product information flows seamlessly across the entire organization.
Discover how ISFsoft Connect helps companies integrate Windchill PLM with ERP systems and build a truly connected manufacturing environment >>
How complementary software increases the value of Windchill projects for PTC partners
The structural ceiling many Windchill partners face
For many PTC partners working with Windchill, growth has traditionally been measured in new customers: more logos, more implementations, and more licenses. In a mature PLM market, however, the real limitation is often no longer acquisition, it is project value.
Windchill implementations are substantial engagements, yet the commercial structure is frequently predictable: platform scope, implementation services, configuration, training, and support. Once the system goes live, the relationship continues, but revenue growth tends to slow. The opportunity becomes incremental rather than strategic, and many partners encounter a ceiling that is structural, not temporary.
The question, increasingly, is not how to win more Windchill projects. It is how to increase value within each one.
Moving beyond core Windchill implementation
Windchill provides a powerful PLM backbone, but customers rarely view PLM as an isolated engineering system. They expect it to influence manufacturing, quality, sales, service, and aftermarket operations. As expectations expand, so does the potential scope of each Windchill project.
When a partner relies exclusively on core implementation, the commercial conversation remains centered on the platform itself. When a partner complements Windchill with additional, specialized software designed to work with it, the conversation shifts. The engagement evolves from a system deployment into a broader operational solution, and that shift has direct implications for revenue and margin.
Increasing average project value
Complementary software allows partners to address operational challenges that extend beyond standard Windchill functionality in a scalable way. Instead of positioning every additional requirement as custom development, partners can introduce productized capabilities that expand functional coverage without compromising the integrity of the core platform. The outcome is typically a broader proposal, clearer value framing, and higher overall project value.
In practical terms, this changes the dialogue from “implementing Windchill” to “maximizing the impact of Windchill across the business,” which is a fundamentally stronger commercial position.
Unlocking post-go-live expansion
Many Windchill projects follow a predictable lifecycle: analysis, implementation, stabilization, and then a quieter period where activity slows. Complementary software changes that dynamic because customer needs do not stop after go-live—if anything, they become more specific once the platform is in daily use.
As customers mature in their PLM journey, new needs naturally emerge: improved access to product data beyond engineering, enhanced visualization for broader teams, integration with downstream processes, and usability improvements that accelerate adoption. Each of these moments becomes an opportunity to expand the solution footprint and extend the engagement in a structured way.
This is where partners move from being implementers to becoming long-term solution architects, continuously evolving the customer’s Windchill environment.
Strengthening recurring service revenue
Every additional solution integrated into a Windchill landscape generates associated services: consulting, configuration, integration, optimization, training, and support. Partners retain full ownership of the customer relationship while expanding recurring service streams around a stable software foundation.
Just as important, this approach reduces dependency on custom development. Custom code can increase short-term billing, but it often introduces maintenance complexity, version compatibility risk, and delivery overhead that erodes margin over time. Independent, productized software designed to work with Windchill offers a more scalable and sustainable path, especially for partners focused on repeatability and long-term profitability.
From project volume to project value
In an ecosystem where multiple partners offer comparable Windchill expertise, portfolio strategy becomes a primary lever for differentiation and margin protection. Complementary software is not about replacing Windchill; it is about reinforcing it with targeted capabilities that expand project scope, unlock post-go-live growth, and strengthen recurring revenue.
Partners don’t need more customers. They need more value per customer.
Expanding your Windchill portfolio strategically
At ISFinnovation, we develop independent software products designed to work with Windchill, helping PTC partners expand project scope without increasing delivery risk. We work exclusively through partners.
If you are exploring how to increase the value of your Windchill projects and strengthen your PLM offering, we would welcome the conversation.
Become an ISFsoft Partner >>
From engineering data to production control: aligning Windchill and ERP in high-growth manufacturing
In Barcelona, Stark Future is redefining performance in the electric motorcycle industry. With more than 100 engineers and operating in one of the fastest-growing segments of the global EV market, the company combines engineering excellence with an ambitious growth strategy. But in high-velocity manufacturing environments, innovation alone is not enough. Without structural control, growth quickly exposes weaknesses in data management and system integration.
At a critical stage of its expansion, Stark Future faced a challenge that is common in fast-scaling industrial companies: how to transform engineering data into production-ready structures without losing accuracy, traceability or time.
The challenge: aligning Windchill with ERP reality
Stark Future’s engineering environment was based on Windchill PLM from PTC, where product structures were defined and managed as Engineering Bills of Materials (EBOM). However, translating those EBOMs into Manufacturing Bills of Materials (MBOM) ready for production — and reliably connecting that information to Microsoft Dynamics ERP — was not automated.
The transition relied heavily on manual data handling. Engineering and manufacturing teams were not fully synchronized at system level, and changes required effort to track and validate. In practice, this meant product structures were exposed to inconsistencies, delays and operational risk. At the pace Stark Future was growing, this gap between PLM and ERP could quickly become a structural bottleneck.
The problem was not the quality of engineering. It was the absence of a controlled, automated integration layer between Windchill and the ERP.
The solution: structured integration with ISFsoft Connect
To address this challenge, ISFsoft Connect was introduced as the integration layer between Windchill and Microsoft Dynamics. The objective was clear: establish a structured, automated and governed data flow between engineering and manufacturing, eliminating manual intervention wherever possible.
The project began with a thorough pre-analysis phase to define scope, risks and integration requirements. Particular attention was given to defining precise EBOM-to-MBOM transformation rules, ensuring that what engineering designed in Windchill could be consistently and accurately translated into a manufacturing structure aligned with ERP processes.
Rather than treating PLM and ERP as separate initiatives, the approach aligned both environments from the outset. The integration ensured that product releases, revisions and changes could move between systems in a controlled and traceable way, creating a reliable digital thread across the organization.
The focus was not limited to technical connectivity. It was about long-term reliability and scalability. In high-growth contexts, short-term fixes create long-term instability. The objective was to build a foundation capable of supporting Stark Future’s expansion without constant rework or manual corrections.
The impact: a single source of truth at a decisive moment
The results were structural. Stark Future established a reliable method to derive MBOM from EBOM, fully connected to the ERP and free from manual duplication. Errors associated with manual data entry during product structure development were eliminated. Product releases became instantly controlled, and change management gained full traceability across systems.
Most importantly, the company achieved what every fast-growing manufacturer needs: a single source of truth between Windchill and ERP. Engineering and manufacturing now operate on synchronized data, reducing risk and increasing operational confidence at a critical stage of growth.
In industries evolving as rapidly as electric mobility, scalability depends on integration discipline. Stark Future’s case demonstrates that aligning Windchill with ERP through a structured integration layer is not simply a technical improvement — it is a strategic enabler of controlled growth.
If your company uses Windchill and is struggling to reliably integrate it with your ERP, we can help you design a controlled, scalable integration strategy. Contact ISFinnovation to explore how to eliminate manual bottlenecks and establish a true digital backbone between PLM and ERP.
Contact our team >>
Discover more about Connect >>
PTC partner differentiation strategy: Moving beyond core Windchill implementation
For many years, building a business around selling and implementing Windchill was enough. The technology is robust, the ecosystem is established, and demand for PLM expertise remains strong.
But the environment has changed.
Today, most official PTC partners offer similar capabilities: certified expertise, implementation experience, and platform knowledge. What used to differentiate a partner is now simply expected. When portfolios look the same, conversations quickly shift toward price, delivery time, and discount structures. That is not a sustainable position.
The reality is simple: core PLM implementation has become a baseline capability, not a differentiator.
Customers don’t buy platforms. They buy operational impact.
Industrial organizations are under increasing pressure to shorten development cycles, improve collaboration, and connect engineering data to business decisions. While Windchill provide a powerful foundation, customers frequently discover that their real operational challenges extend beyond standard functionality.
They are not asking for “more PLM.”
They are asking for:
- Better accessibility of product data
- More intuitive ways to visualize information
- Stronger connections between engineering and business processes
- Faster deployment of practical capabilities
These expectations do not necessarily require modifying the core platform. They require expanding the functional scope around it. This distinction matters.
The limits of competing on the core stack
When multiple partners sell and implement the same platform, the competitive field narrows. Expertise becomes assumed. Certifications become standard. Even project methodologies start to resemble one another.
In that context, differentiation must come from portfolio strategy.
A reseller mindset focuses on licenses and implementation services. A solution partner mindset focuses on delivering measurable business outcomes. The difference is subtle but decisive.
Solution-oriented partners look for ways to complement the core PTC stack with specialized capabilities that respond to recurring customer demands. They reduce dependence on custom development and instead build scalable offerings around proven solutions.
That shift changes the commercial dynamic entirely. Projects become broader. Conversations become strategic. Margins improve.
The hidden risk of custom development
When customers request functionality beyond standard Windchill capabilities, the natural reaction is often custom development. It promises flexibility and tailored delivery.
However, over time, custom code introduces complexity: maintenance overhead, version compatibility challenges, dependency on specific developers, and increased delivery risk. What begins as differentiation can quickly become technical debt.
Scalable partners understand that not every requirement should result in a custom extension. Sustainable growth requires repeatable solutions, not isolated projects.
Expanding beyond the core strategically
The most resilient PTC partners are not those who abandon the core platform. They are those who strengthen it by surrounding it with complementary, independent software designed to work with Windchill.
This approach allows partners to increase project value without compromising platform integrity. It enables them to address specific operational needs while maintaining scalability and roadmap alignment.
More importantly, it positions them as strategic advisors rather than transactional implementers.
In an ecosystem that continues to mature, remaining static is not neutral — it is regressive. Customers expect more integration, more usability, and more cross-functional impact from their PLM investment. Partners who expand thoughtfully will lead. Those who rely solely on core implementation will increasingly compete on price.
Differentiation is no longer optional. It is structural.
Some PTC partners are already exploring how independent software products designed to work with Windchill can help them expand their offering without increasing delivery risk.
For companies ready to move from license-driven sales to value-driven solutions, the opportunity is clear.