Aras and OpsHub

So today’s topic is on Aras and Ops are driving smarter connections for faster innovation.

a warm welcome to our three presenters here today. First my colleague John Sperling, who is the VP of Ecosystem Solution development here at Aras. And then, two, Punit and Aparna from Ops Hub, a partner is a product marketing director at Ops Hub, and Punit is the Digital Thread Solutions engineer. So with that, John, do you want to get us started?

Yeah. Thanks, Brigitte. Welcome everyone. So I wanted to talk about a little bit about my role there. What is ecosystem solution development mean anyways? So, we understand that, well, PLM is a cornerstone of what you do in engineering and manufacturing processes. There’s many other things in your own ecosystem that you need to connect to.

And so because of that, we have if you’re not aware, we have, what we call the Aras marketplace. And these are the ecosystem solutions, that you can add on to your Aras environment, whether they be applications or integrations. And quite a few integrations here, including from UPS hub. So just wanted to, you know, you’ll be seeing a lot about their product today, but if you want some more details to read about, you can find that, here in the marketplace.

And with that, I’ll pass it over to a partner and take you through their offering.

Thanks, John. And, hello, everyone. So, meeting the slide. So before. So the session is about, what is digital threat? The challenges organizations typically face in digital tech, followed by a live demo. But before we dive deeper, we wanted to set foundation by clarifying three terms that are often used interchangeably, but have very different meanings.

And those three terms are digital, digital, digitalize, and digital threat. So digital, digital simply means taking what exist on paper and making a digital version. And what exists on paper is typically a static document out of sight. This is an important first step, but it does nothing to improve sort of cross-functional visibility or continuity. Digital just creates digital copies of the information that is there on paper today.

The second is digitalize. Digitalize connects information across the systems. It eliminates isolated data pockets and allows the flow of information across engineering operations and quality. But, the connections are still point to point and fragmented. So there is no one digital thread connecting the systems. All the systems or two systems are connected separately. The other two systems are connected separately.

It’s like that. The third is digital thread. And, this is the end goal. So this is about enabling full lifecycle traceability where every change, decision requirement and verification activity can be followed seamlessly across systems. The systems like PLM, ILM, MSC, Quality Management, ERP and you name it. This continuity is what unlocks the real compliance, real speed, real cross-domain collaboration.

So getting this distinction, right in the is the very foundation to achieve lifecycle continuity across tool chain. The distinction right between digital digitalize and the digital threat. Just quickly going through some use cases. Digital threat is relevant to many industries. We have just shot big three industries over here. DoD aerospace, semiconductor and Healthcare and Medicare. Like if you take a talk about DoD weapon lifecycle weapon system lifecycle traceability.

So when a weapon was purchased, it’s maintenance, it’s deployment, it’s versioning, what change took place, etc. Every whole traceability of that weapon is traced or traceable across the system. Similarly, securing a secure supply chain integration, maintaining data, interoperability in semiconductor again supply chain fab yield management collaboration across the Fab ecosystem. So like if I take an example, if we take a requirement that it traces to all the verification trace test that were done, or in fact before verification test, if you take a requirement, then it traces to all the changes that happened related to that requirement, all the verification tests that ran against that requirement, the result of the those verification test, everything is traceable from the systems.

And similarly health care to healthcare again design to compliance traceability. So reports audits reports compliance reports. They don’t need changing people in teams here and there using emails to get the reports on time. The reports are available 24/7 365 days because it’s there in the system itself. So, now that we have understood the difference between digital digitalize and digital threat, let’s look how to, what are the typical challenges that comes in achieving the digital threat?

And this will help, this helps organizations to identify. So if we are trying to establish digital threat and we are still facing these problems, then just see if it is digital solution digitalize or the digital threat solution. So like the first challenge is juggling multiple updates. So if you are just digitalizing or creating digital copies, teams will still spend enormous time reconciling spreadsheets.

Reconciling means you can selling, the data across the systems. Everyone maintains their own version of truth, which creates unnecessary manual effort and delays. The second challenges there is no digital. There is no single source of truth. So disconnected systems leads to mismatched, mismatched systems. Different teams are working on different requirements. That is lead discovery of issues. And then the third is I can’t deliver insights.

So I data is the fuel of AI. Depends on clean connected data. When information is fragmented I can’t generate reliable insights. So the value of digital trade remains limited. So these are the signs that, it’s not the true digital trade is probably maybe the digital digitalization is done. Maybe the digital copies are created. But, teams are not seeing the benefit or the results of it.

And with that in advance, now that we know digital digitalize and digital trade even on the journey of digital trade, these are some of the common challenges we see consistently see across UX. So to summarize, most digital threats require extra steps forcing processing using large scale retraining. So what that results into is for adoption. The adoption becomes a hurdle because teams are asked to learn new tools or follow new workflows.

Resistance naturally builds up. If process feels heavy, it slows time down. So they they sort of push it, push the digital trade back. The usage drops quickly. And once adoption suffers, the entire digital side effort loses momentum. So it ends up being a change management project instead of a digital side implementation project. So watch out for adoption, user adoption.

And then the second challenge is poor data quality. So a lot of information still travels through emails or let’s say the information is incomplete, which introduces errors and delays. So and when teams can’t trust the data, they hesitate to act on it. And the thread breaks before it even forms.

So, the the first challenge was poor adoption. Second is poor data quality. And third is low value at there is often missing in system traceability tools. Don’t talk to each other. Relationships are not sinking. Files are not sinking. Comments are not sinking. So the insights remain superficial and without real time connected information, organizations struggle to realize the full benefits they expect.

So these challenges sort of highlight why many digital trade programs stall. Because why organizations are trying to implement digital threat. It turns into a change management project. It turns into a data cleanup project. It turns into a ribbon replace of tool chain project. So there are some projects that are created. So watch out for that. Keep it the digital type project.

Don’t let it turn into a change management or migration project. And there are some, and rather than identifying. So when you go about picking a digital trade solution rather than identifying these challenges solution by solution, what we do is, we have created buckets to mostly all the digital threat solutions fall in one of these three buckets.

So you can pick a bucket, let’s say if you want to go with centralized external digital trade, then go for solutions that falls under that bucket. Or if you want to go for federated digital approach. So at category level, understand the challenges and the benefits of that approach. And then any solution in that category more or less will typically, serve those benefits and will have those limitations.

So the first approach is UI integration. This is essentially UI level, creating a virtual thread by pulling information from different tools into a single view. So as we can see in the diagram here, we are trying to put a small architectural diagram, to help understand the concept better. So UI integration is typically you install a plugin in each tool.

So there is this, each red dot over here is a plugin. It’s a, there is a plugin installed in JIRA. And for just example purpose we have technical IBM tools. And that is but it can be any other tool with that is. So there is a plugin installed in Addis that is a plugin installing doors. And there is a plugin installing JIRA.

But this plugin does this. If you click on that plugin it lets you view the information in other tool. Typically updating of information is not possible. It’s for you only. So it does not create duplicate records. It is lightweight, but it has for adoption because one is not all major PLM or DevOps tools fully support the plugin or the OSI model.

And in this case, because the data is not there in other systems, if let’s say JIRA is down, then users in others users in those won’t be able to view the data, so they will also their work will also come to point. And because data isn’t aggregated and aggregate reporting or compliance reporting is not possible. So for compliance reporting, even after this integration, you will have to have some other solution that gets the data together at one place.

The UI integration typically does not lead to a complete digital thread. Solution. I hope that is clear. If there are any questions later when we open the Q&A, please do feel free to ask. And then the second approach is centralized external digital thread. So this introduces a dedicated digital thread platform that as we can see over here again for example, the example purpose we have taken at least in IBM goes along with that is.

So all the information from all the tools is sync to the central digital thread platform, and the digital thread is created in this third platform. So the digital thread is not there in address is not there in those. The thread exist in other external third tool that for digital thread only. This creates a strong unified view of the lifecycle, but it comes with its own trade offs.

So team all the teams needs to learn now this new interface. So JIRA users tools users, others users they will have to learn this new interface again for adoption. High rate high training required users are required to log into this additional platform, leading to adoption challenges. And since everything the routes to one system, it becomes a single point of failure and limit scalability.

Because now this one system needs to house data from all the tools in the tool chain. So that is centralized external digital thread. And the third is federated digital thread. So here this model focuses on connecting systems while allowing users to stay inside the tools they already work. So in a while we will also do a live demo to give a glimpse of what this federated digital thread creation looks like.

The thread is created by enabling systems to exchange contextual information rather than centralizing the data. Again, as we can see in the diagram here, there is a, there is a, intelligent federated platform in center. And all the systems that once that are part of digital thread are connected via this platform. So this platform basically facilitates the communication between two other engines, between two other systems.

So if address and data needs to be integrated, both these will connect to the central platform. And the platform will take care of all the transformations, all the configuration. Six you know data, the differences. No data is actually stored in this middle layer. This layer is just facilitating the exchange of information between the systems. But no information is stored in this layer.

Unlike centralized external digital state. So this approach tends to reduce retraining since users interact through familiar interfaces, they don’t need to learn any new process. There is no retraining required. It provides resilience because even if one system is down, like even if let’s say JIRA is down, but Aras and those users will still continue operating because they have the relevant data in their systems and it preserves data governance because ownership and storage remains with the originating system, you do not need to set up separate data governance in a external digital threat tool.

So the if all the teams, all the tools continue to work just like they were working before digital implementation, this really brings down the, barrier to adoption, barrier to data quality or barrier to value addition. So understanding these three approaches, is crucial because, if these three approaches are clear, then, all the challenges that we discussed barrier to adoption for data quality and the low value add will follow will fall in one of these three approaches.

So you can pick like federate federated offers lowest adoption barrier. It results to no change in the user workflow. It offers rich data flow and the highest value add for AI initiatives a centralized digital threat. There is high barrier to adoption because users need to learn. The third tool, data quality still will can be this data quality still, you know, then the third tool needs to support all the formats.

For example, Atlassian Jira shows the formatting in wiki format, Aras’ HTML. Doors has objects as well. So then the same the central digital threat to needs to be like like in terms of feature wise, wide enough to be able to support all these formats, which is typically quite difficult to attain. So, now we will move to the demo.

It’s quite big demo. So what we have done, it’s the actual demo is integrating Aras with MSI tool. In MSI, we have taken cameo, which is being integrated using a custom developed connector using a custom developed connector. And this is then the digital thread is endorsed. These four systems are connected, but as, shared, it’s quite a long demo.

So what we will do here is, keeping time in mind will show glimpse of digital thread between Aras doors and Aras Jira. And for the whole demo we have recorded it. And you can scan this QR code over here to get the video recording of the demo. And we will also be sharing the link with you.

After this webinar. So with that, I will pass control to permit. He will give the live demo and then we’ll move back to slides. So Punit, our team.

Yeah. Thank you. Open up for giving this set the stage for this live demo. Hi, everyone. I’m Punit from Observe India Today as Aparna mentions. Will, be creating a digital trading across from IBM, DOORS and data. So I will just, show you my screen. This is second.

Okay. Let’s go. So will creating, digital thread and Aras from IBM do then data to bidirectional same digital thread for part and task specification between Adarsh and data. And then how to change request in r us to next IBM to keeping requirements automatically sync. So let’s first go with first part across India. This is my this is my vanilla eras.

I would say what is vanilla. That is we don’t have any custom plugin or external script involved. The Federated Digital Thread engine observe is running in the background on separate machine, enabling sync between Aras and data. So as the arise user, I will just create a part in the part entity. Let let’s, let’s create one, part.

I will give some. Number. Let’s give some name.

We’ll have some rich text description includes, some texting, this filled text and some bold.

I think, like.

I will add some bullet.

I will save it. Now, notice I that it arises. It does not need to do anything extra like exporting or manual triggering for a thing. I will just save it and done. Now notice I have just saved it and done option in the background will fetch it and sink into an epic entity or any other issue depending on the configuration.

Without us user performing any additional action will also create a task from there. Let’s create a task.

Task one from. Let’s. Let’s call it task one.

Task one from I don’t. And I will just save it.

Done. What I have done is I have created this part mainboard part for PCB will have the task and description. Now let’s go. Isn’t crazy mainboard pro apart from PCB, what we have in the is the same title, the same description with the same formatting that text formatting. Now let’s do one thing. Let’s change this description to check whether we get the same updates in us.

Let’s do one thing. I will say change from tilde and also will bold this from zero. And let’s save it. Will also look at.

The task which we have got from I us. This is a task that we made in Aras. That’s one description is task one from Aras. This is like crazy. And you, you see the link work item? It is the the links are the relationship with the part that is an epic in data. Crazy that let’s let’s move to Aras and see if you have got this, changes which we have done from zero.

Let’s refresh.

Wow. It’s simply so pretty. We have see, we have seen this description in the bold PCB part change part from data. So we have got the changes from TDA into Aras in real time without any manual work or manual change actions from data user to it’s all federated digital thread. So that means the users keep working in Aras as usual and digital thread.

Complete completeness is not dependent on any manual actions like like triggering and is saying or this exporting from across or different tools. That’s great. Right now, this is this was about the Aras and data. Let’s go for Aras and IBM and this create CR requirement in Aras. It will get sync in the real time as it got in data.

Let’s, let’s Create. Change requirement for our production I will just add some description. Sample requirements are listed below. I will add some bullets. Requirement one. Requirement two. Requirement three I will just add it. And obviously it’s up from my manager right. So I will just save done. You know same thing as Aras that I’m not doing anything.

I’m just saving. Observe will fetch it from this see requirement and sync it in IBM Doors without any manual effort. It without any manual actions like triggering or exporting nothing. I’m just doing my usual work as a Aras user. So we have this will show you. So we have just made it change request for production will go to IBM Doors.

Let’s go to IBM Doors. This is my IBM Doors and it will get sync in requirements.

A split second.

So I have created this Aras. I have created and edited saved it. So let’s say.

This saving it done.

You will see the CR.

Crazy. We got the same requirement for production which we wrote in Aras at the same time. Real time, no manual efforts needed. We just made a requirement in Aras and it got signed in IBM DOORS. So let’s do one thing the same we did for Aras. Let’s do let’s change this title from IBM DOORS. And let’s see if we get updates in Aras.

So we’ll change this title.

This bit slow. This wait.

I guess it got hanged.

Might be a technical glitch in those.

Maybe a technical glitch in IBM Doors, but you got a point, right? We just, create entities and in the real time and just, we just, in the real time, we get the same update from different, I would say, systems or tools in real time without any manual effort. That’s the power of federated digital thread.

That’s all for my site. Thank you everyone, and thank you for your contribution. I appreciate that all too. I will just give my mic to, open for the next state. Thank you.

Thanks, Punit. Thanks for, wonderful demo. So, just to summarize in the demo, what we saw was to create to facilitate digital thread between ARAS. And the other tools in MSI PLM, like, you know, codification, other tools, the users in the respective tools can just work as usual. The digital thread implementation can remain transparent and seamless to them, so they don’t need to know about digital thread or what is required.

There is no dependency on the end users policy, but digital thread is the digital thread. Implementation or facilitation is completely seamless and not depending on each user in, all the tools, in all the tools in the toolchain. So that increases the probability of a successful digital thread implementation. And the second we saw in the demo was rich data quality.

So in Aras the images that Punith had put, all the images were there in GDA as well. So the view or the data and this user was seeing the same data. A JIRA user will see again here. When I say same data, there can be filters like pick something from Aras to Jira only once a checkbox is staked, or only once some status is approved or anything else.

So there can be trigger conditions as to when some are given, what data needs to be moved to other tools, and, on what condition the data should be. So rather than keeping that manual, the whole thing is automated so that at the end of the day, you get a reliable and a predictable digital thread that you know is complete and will work.

So with that, just a quick land landscape view of all the tools, observe supports for creating digital thread. So like Aras, with all the IBM, IBM Doors in ATM, RTM, Jamma, JIRA, ServiceNow, Azure, DevOps, OpenText, PLM, Zendesk, Broadcom. There are roughly 70 plus tools already supported out of the box. So when we say out of the box, that means there is no, there is no development that needs to be done.

These systems just needs to be connected to that. Federated platform, federation platform. And once it is connected, the information exchange will happen. But the configuration and, for all of these platforms, no plugin installation is needed. And all the users will just continue to work as they were working before the digital thread was implemented by the digital thread stakeholders.

You will see the required reports and data in the tools.

So, just in going, some wanted to summarize some best practices for digital thread implementation. Like when we talk about implementing digital that it can sound big and abstract, but in reality success comes down to some of these very few practical habits that make life easier for the team to use these systems completely. So the first is move from digital to digitalized to digital thread.

A lot of organizations stop it simply digitizing the documents. But the real value comes when, we start connecting the data behind those documents. That’s when things start seeing the value and everything fits together. Second best practices minimize or make it to zero. Not even minimize. Make it to zero. Adoption resistance. No one wants another new tool or another new process.

I’m sure all of us have plenty of processes in our life, so the less we ask people to change their day to day workflow, the more likely they are to actually use the digital data. It should blend into the tools they already know, rather than the pen replacing the tools or moving them to a third tool, or asking expecting them to perform a manual action for their digital threat to be creating, make the thread reliable through automation.

So if the trade depends on people remembering to update, remembering to, you know, click sync manually or export manually, then it’s going to break because we are talking we are not talking about two people. Three people, we are talking about thousands of people. And then the digital thread success is dependent on every one clicking on that sync button.

Every time. So automated sync ensures things stay up to date in the background so teams can focus on the work that matters. And then, like in addition to digital thread creation, also use this opportunity to let teams collaborate from their own tools so they don’t need emails to collaborate. Different teams lives in different systems. Half of the information is there in the in systems and and actually more than half of the information is there in the emails.

So goal isn’t to force everyone into one tool, but to let them collaborate, without having to switch back and forth or sending long email chain. So by having them use the tools of their choice, avoid procuring a separate digital state solution for each connection. So if you’re if you want to create digital thread with at us and those at us and the Edison and BC Edison service now avoid procuring a separate digital thread solution for each of these combination, because keep it that, keep it a digital thread project and not a change management project, a migration project or a procurement project.

So bring down the tools or the software you will be acquiring to implement a digital thread. And a better approach is connecting the systems you already have instead of setting up a stand, separate platform for every domain, enable teams to do aggregate reporting from native tools so teams should not have to export data into spec sheets from different tools to get together.

Just to get a clear picture. A good digital thread makes it simple to run cross system reports from the tools they already use. Plan for change. This is very crucial. And this is one of the key problem with plugins because tools evolve, schemas evolve, version upgrades happen and business needs evolve. So the digital thread has to be flexible enough to grow with the organization to grow with, as the tools are getting updated and not something that breaks with every time a process changes.

So in the end, a good digital stage should feel natural natural to what users are already doing. Something that supports how people already work and not something that have to fight against the. When we get these, basics right, the rest becomes much easier. When it comes to digital threat. With that, I pass it on to John to talk about how digital threat can be a strong base for AI.

Thank. Well well said. And to emphasize the importance of what she’s been talking about, I wanted to share a little bit about our view of AI and AI leveraging the digital thread, because, as she showed earlier, if you don’t have that thread, you don’t have the context to make decisions. So we think of, you know, as the, the platform being this, supporting applications across the lifecycle.

We have, a lot of that digital thread already inherently within our system, but there are things that, you are always going to need to talk to that are external. But doing that efficiently and in a way that, attracts users to, to actually making use of it is is what we see is is critical here.

And so this is how some fits is especially in some of these upfront tools, ALM, MBSE requirements to bring that into your Aras environment and and make things consistent across the enterprise. So, lots coming from Aras in the AI space. Soon. So stay tuned for that. But, we see Ops Hub as being, a key player with us to make that all happen.