Doing Things the Right Way?

In a previous blog, titled Doing the Right Thing, the question was if we would add value if we shifted focus from a processes centric approach when implementing a PLM tool. Today it's time to look at the other side of that coin - why would you want to focus on doing things the right way, or in other words being process centric? And to repeat - the main point here is not to dwell over the question if we need business processes or not, it’s about creating IT support for them in a PLM system, or not.

First of all let’s be frank; it's not necessarily the right way we are talking about, it's more a way; a way that has been chosen as the "right one". The criteria of being the right one could be many; what we know to be the best way at this point in time, a way prescribed by a standard or required to become compliant, or simply something that the stakeholder could agree upon.

So why would we want to implement processes into an IT tool?

• Compliance to different standards and regulations is a huge driving force. Being able to enforce and show auditors that you are following the directives prescribed by a authoring body is sometimes a good enough argument. Having change management, review processes, approval processes, follow-ups, document management, history records, etc supported by an IT tool makes life easier (even if your business isn't regulated), at least if you have the right IT support.
• Consolidate and unite companies/subsidiaries/sites/etc in their way of working it's quite often a requirement for initiatives such as joint manufacturing facilities, sourcing, procurement, eCommerce, PIM, or effective after-market support. But I would dare to say that in most cases it's more about securing the data rather than the processes. Call the cards, and you will probably find that besides the initiatives listed above the motive could be found among the softer aspects of implementing IT support for a process - unification across borders through enforcement, thereby creating the notion of one company.
• Complex development processes which require consolidation and exchange of information across multiple disciplines and organizations will also have a great benefit of harmonizing data and processes using a system to support their tasks.
• Scalable "know how" as it's captured in the tool allowing it to guide people in their work. Phase-in of new employees will thereby be easier if there is process support guiding and enforcing the user in the way they should work.
• Improve and enforce quality as you get control and are able to guide users through the companies working procedures
• Automatisation of process steps will become much easier as we have a repetitive flow of events

So as you can see; there is no "That is the question" in Hamlets monolog. It all depends. There are basically advantages of both approaches. And that is how it is; depending on your needs (some could perhaps be more justified than others ;) you could see the advantages of getting a PLM system to support your processes. But don't take it as something that you have to do! If you start using the approach from the previous post as a "reflex standpoint" - don't tie down your IT system with intricate rules to support an ever-changing process, then I bet you will get a better Total Cost of Ownership (TCO) at the end and a happier customer (the end user).

Robert Wallerblad

www.infuseit.com

Doing the Right Thing?



This post is inspired by a definition found in the comments which followed Oleg's post and a discussion with a friend of mine who is PLM responsible at a small car manufacturing company.

First, let's apply the definition of processes and practices, that Michael Grieves use:

“Processes are well defined routines that give organizations the outcomes they desire. However, a great deal of what companies do, such as innovation, is driven by a desired end result, which is what practices are all about. “

You could also rephrase this to "processes are about doing things the right way”; dictating how work should be done. Focusing on the what instead, we would allow decisions by knowledged workers and IT automation determine much of the how.   

To generalize, traditional PLM implementations are focused on data capturing and processes (according to the above definition). Capturing data in a common repository enables transparency, access and being able to connect the dots (data) in new ways. Usually, we then cover the data with a process layer, targeted for effective and repetitive management of that data. 

But what if we would focus on supporting “doing the right thing” instead? What would that mean? For me, that would mean focusing our effort on data, functions to manipulate, communicate and collaborate around it. Another critical role for a PLM tool would be to have capabilities to analyze that data, helping workers make informed decisions which would allow them to “do the right thing”.  

Are we on to something? What about "best practice" processes? Could we say that we can deliver value without them? Can we do this without being banged in the head by sales and marketing saying that we can't sell without a out of the box process support?

What if we state that "best practices" are on data level, basically how we choose to model the reality in a smart way? But to not become a consolidating integration hub, we would have to have tools to manage that data accordingly. With decoupled features we then address "best practices" of managing data without "tying it down" with processes.

To not "just" become a good data management tool we would need to wrap the whole thing with communication and analytic capabilities allowing the user to collaborate and making “the right” decisions.

What would we have then?

- A replacement to mail, excel and other data silos, which was exactly the thing that my friend at the car company was asking for; a tool which would allow him to still have the required flexibility but with transparency and the synergy of previously disconnected data sets. This would give him the means to reach the desired result in a perhaps unstructured way but secured via data and supported through communication and visual analytics. Wouldn't that add value? Wouldn’t that create an innovation pull as we then focus on "doing the right thing" rather than paving complicated cow paths?

Robert Wallerblad

www.infuseit.com

Looking beyond the Social Hype of Enterprise Collaboration Tools

Starting a discussion about enterprise collaboration tools the “visionary” individual in the group says: “I want Facebook for me and my colleagues”. And as Ed Lopategui and Oleg Shilovitsky pointed out in their blogs last weekend - Facebook and social platforms are probably not exactly what she should be looking for. So instead of getting fooled by the allure of marketing promises of social enterprise tools what should she be looking for? 

What Facebook and actually most other social applications are providing is not only a real-time chat but something that is asynchronous and persistent and doesn’t require that someone is actually receiving the message at the point in time when it is sent. Due to the global environment in which companies are working in today this is a “must have” as time zones would be a too much of an obstacle otherwise.

Many collaboration tools are coming from vendors already offering CAD, ERP, CRM, PLM, etc but these are primarily focused on the users and practices of that specific system. It’s basically not user centric! If you would take the users standpoint in such a solution you would easily see that you would allow for cool collaboration but only within the island of that application … and for the end user that is not enough - how many are there living in a one-app or even a one-suite world? So we need something that has crossed the application barriers and can work stand alone or integrated depending on need.

Moving towards a “neutral” collaboration platform would also be a step forward to enable a nowadays quite popularly addressed part of enterprise collaboration – the one towards the suppliers. Not only would we have the “normally” implemented structured exchange of information in place, it would also enable us to support the more unstructured and ad-hoc part of it. Moving away from mail and creating a more transparent way of communicating.

This takes me to the next point – Transparency. When I say transparency I don’t necessarily mean that everything is accessible to anybody. But you can share and you can collaborate across disciplines and multiple users without having to cc each other like you do with a mail! This is a key feature and required if we want to break out from the silos that emails are creating.

So what about mail then? Well, I wouldn’t be so bold to say that mail will disappear the next coming years, but we could definitely fight to reduce the volume of messages going back and forth. With good hooks and APIs to import and generate emails and to plugin and expose features in other tools and portals I bet we could give it a good fight too ;)

Another thing with mails is that it allows the user to structure her things in her way. Creating folders and tasks are features which allow the user to create her world and semantics. Allowing her to find and organize the information in her way.

The thing that neither Facebook nor email has is context – the user is the context in these applications. To bring the features of email and Facebook into enterprise collaboration we need to hook it into an item context. And that is exactly what the vendors of the CAD, ERP, CRM, PLM tools offers – the right data context! But only from their application point of view! Users are working within processes supported by multiple applications. In reality “the context” is something moving across multiple applications and across functional domains and we need to treat the communication the same way.

Tying together most of the features implied above is the accessibility and searchability – for the communication, collaboration, transparency, email, and context to be worth anything you really need to be able to find stuff.

So now I have stated some features I consider important when thinking about collaboration tools. Although being good, they bring some softer challenges to the table, which might be easier to mitigate in current collaboration solutions.

One challenge is to do the right thing in the right place and in the right forum ... and still making it understandable to the user.

• Data in the “right” place - will we create a mess and store important information in a too unstructured way?
• Decisions in the “right” place - will decision be made invisible and will we lose the formality required of some decisions? Statuses, do we need them anymore ;)

Then we have an obvious challenge - getting people to move from a silo mail-world to a world which is no longer under “my” control. Transparency is scary. There is no way around that.

So to summarize; Facebook is probably not the way forward for enterprise collaboration tools and there are some challenges to address on both technical and a human level with today’s collaborative tools. One thing is for sure - just because we might re-label "the solution" from time to time the need will still be there. The problem is when the label brings assumptions to the table which are not suited for an enterprise collaboration tool. I'm sure that we will get past the current misconceptions and as collaboration and digital technologies are advancing it will allow us to solve our challenges though new influences and tools. 

Robert Wallerblad

www.infuseit.com

The Achilles' Heel of Data Modeling Standards

The benefit of a data standard is obvious - being able to share and exchange information and integrate business processes in both early and later stages of a products lifecycle is a tempting thought. It also addresses challenges that are high on many executives’ agenda.

Taking standards into an everyday perspective you see the benefit of it in for example electrical sockets. It is also a good example of how hard it is to unite around something as there are different standards of it across the globe. The biggest advantage with a standard is not that it is optimized or perfect; it is that it unites.

Data Modeling Standards has one Achilles' Heel - one has to map the clients business models into the standard model in a consistent way. It is actually the purpose of the standard - same thing should be modeled in the same way independent of source or organization. This is key to success for both the standard itself and the actual implementation of it at a customer.

So let’s try to digest that statement.

If we have a standard which is semantically covering the complete definition of a certain thing, leaving no room for flexibility, there shouldn't be any problem, right? This requires that the area of the standard is mature. An example of such a standard would be STEPs AP214/AP203 (ISO 10303) which covers CAD geometry.

But what happens if you look at standards which are more open for interpretation such as PLCS (ISO 10303-239), or ISO 15926? If it is open for interpretation it can be "misused"; missing the goal of the implementation completely as the intent with the standard is to enable data exchange through the use of a neutral format. But if the same thing is modeled differently we suddenly find ourselves in the normal integration trap with multiple mappings to get to a consistent, homogeneous and coherent information set. Standards like these basically requires that you either have a developed agreement how to apply it for a certain item and business process (in PLCS case a DEX) or that one uses people who more or less embodies the standard and knows by experience how it should be. An alternative is to use a more industry specific standard which thereby is more semantically meaningful and less "error prone".

Taking the road towards standardized data exchange is an easy pick if you do it in a mature area, such as CAD geometry, which has a stable foundation in a standard. But when it comes to jumping on (standard) trains less traveled one should really understand the potential pitfalls in that specific area that one is looking to standardize; the maturity of the standard and its usage, and really understand the reasoning behind the standard and also your own initiative.

Robert Wallerblad

www.infuseit.com