Notifications are fascinating. We are all love to get notified. Alarms, emails, meetings… Later came social notifications such as likes, discussion comments and others. Enterprise systems are sending notifications about process states and many others.
Recent Apple WWDC presentation provided a snapshot about next evolution point of OS/X notifications. When iOS 8 hits, the notification center can easy become a center of universe for your iPhone. The same happens on Android device- notification screen is pretty much in focus of everything.
Wired article Why Notifications Are About to Rule the Smartphone Interface? provides an interesting insight on how notification functionality will developed and what is means for end users. Here is my favorite passage:
Interactive notifications will spur all sorts of new behaviors. (And yes, Android already has interactive notifications, but the ones in iOS 8 look to go beyond what KitKat can do.) Some of these will be simple, like the ability to reply to an email or text message. But they’re powerful in that you can do this without quitting whatever you’re already doing. And this interactivity is not just limited to system apps. Third-party developers can take advantage of this new capability as well, so you could comment on something on Facebook, respond to a tweet, or even check in on Foursquare. But others are going to be radical, stuff we haven’t imagined yet. Once developers begin to really harness what interactive notifications can do in iOS 8—and they will—it’s going to cause one of the most radical changes since third-party apps. With the advent of iOS 8, notifications are the new interface frontier.
It made me think, there is an opportunity for process management tools to leverage notification center ideas as well as use this spot for better experience PLM systems can provide. In most of the implementation, I’ve been involved, PLM systems are using email to get people involved into the communication about changes and process notification. Recently, instant messengers (IM) and live chats came to that place as well. New type of notification system can come to combine all aspects of communication into single interconnected experience. There is one more aspect. The ability of process management tools to capture existing notifications. It can be an interesting opportunity to simplify process planning for organizations.
What is my conclusion? Communication brings a lot of noise and inefficiency. This is a problem we have everywhere. On the other side, process is all about how to get people to perform in the most possible efficient way. It seems to me the new notion of notification can provide some alternative to old email exchange and buzzzzzes of alerts. UX architects and PLM technologiests should take a note. Just my thoughts…
Recent debate on Tech4PD brought back one of my favorite topics in PLM – data vs. process. The topic isn’t new, but it is not diminishing the importance. I found first appearance of my debates with Jim going to back in 2009. Navigate to the following link and read my old blog – PDM vs. PLM: Is it about the process? Another perspective on data vs. process in PLM was presented in my blog post – PLM: controversy about process vs. data managemen. The last one was inspired by Bell Helicopter presentation made during Dassault Customer Conference back in 2011.
Take a moment of time and watch the debate. I gave my vote to Jim. I like his broad perspective on setting organization on the right path with their working procedures. Jim also “packaged” his process opinion together with “file management”, which made me assume that engineers will be able to identify right versions of a specific file/design. What made me feel sad a bit with regards to Chad’s position is his wiliness to focus on how to control all data in PLM – something I have hard time to believe as needed and even possible. To me PLM cannot control all data, but should rely on technologies to make data available for decision (and not only) processes.
The debate made me think about why Data vs. Process is probably a wrong dilemma in the context of PLM. In my view, the right focus should be on “lifecycle” as a core value proposition of PLM and ability of PLM to support product development. In a nutshell, product development is about how to move product definition (in a broad sense of this word) from initial requirements and design to engineering and manufacturing. If I go future, next stages of product definition will be related to maintenance and disposal. To define what represent product on every stage together with what is required to move product from one stage to another is a core value of product lifecycle and PLM.
What is my conclusion? After many years of debates about data vs. processes, I think time came to get to the next mature level of understanding how to get PLM work for companies. The focus on product definition for every stage of product lifecycle bundled together with procedures or requirements needed in order to move between stages can be a new way to define what PLM is about. Just my thoughts…
PLM is all about process management. This statement comes to the play when people explain the value of PLM in the organization. Usually, when you think about process management, your mind is switching to some kind of “workflow thinking” mode, which assumes you need to follow the process from state to state by accomplishing tasks and activities. In every PLM implementation, this is a moment of time, people ask – how do we manage engineering processes? What toolset we need to have to make it happen?
I can see, engineering people, are bad organized. In many situations to run processes among engineers is similar to herding cats. To manage process in an engineering organization is a challenge. This is a place where PLM vendors usually fails to provide a reliable and simple solution. Engineers are asking for additional flexibility and vendors have a tendencies to provide a complicated solutions. Many PLM tools are providing sort of Workflow designer to create a process model. Later on, you can discover that engineers tend to abandon these processes. Main reason – these processes are not reflecting the reality. I wanted to come with some ideas how to fix that. I came up with the three definitions – tasks, engagement and information context. Take a look on the picture below.
The overall engineering process is described as list of tasks (above). This is the simplest way to present what needs to be done. It easy to digest and follow up. At the same time, the activity around this task list is not linear. In order to accomplish the task, an engineer needs to engage with additional people. This a typical situation when a person who leads the process needs to communicate with other people and comes with the result. Often, it is ad-hoc communication that cannot be formalized resides in people’s mind. Another situation happens when an engineer needs to bring an additional set of information to accomplish the task or make a decision. To combine these activities together is not a simple thing. Workflow is a wrong tool to solve this problem. To support a simplified task management tools with the ability to manage external engagement and connect to information context can be a potential solution to the problem.
What is my conclusion? The simplification is a key word to summarize my thoughts. In many situations, engineers will prefer a simple task list to get things done. However, tools need to provide a collaborative capabilities to connect the engineer’s activity to other people and additional sources of information. Just my thoughts. I’m interesting to learn how you manage engineering tasks in your organizations.