Well, looks like Mike Payne is at it again. The man that’s notable for starting a good number of CAD companies, including PTC, Solidworks and Spaceclaim, is making another run at it. But this time, it’s a little different. While I was out at Solidworks World in mid-February, I had a chance to sit down with Mike and the folks at Kenesto to get an introduction to their new product. This post provides an overview of the background of the company and what capabilities the software system provides. You’ll find my thoughts on it as well.
Background
There’s not much on Kenesto as of yet. The company was founded last year. They’ve been developing the product since the fall. They say the product will launch ‘when it’s ready.’ You can find out more at Kenesto’s web site.
Capabilities Provided
What exactly is Kenesto? What does Kenesto do? Here’s a run down of some of its capabilities.
- Kenesto provides something that looks like a routing engine that supports the execution of ad-hoc processes. Essentially, one user can create a task and send it to someone else. No process template needs to be selected. That next user then determines how to execute their step in the process which could include launching three new tasks for three other people or simply performing some actions and returning the task back to the original user. There doesn’t have to be any predefinition to the process in any way. It’s organic. It’s defined on the fly.
- Kenesto lets everyone see the status and, if necessary, change the path of the process. If a process has gone awry because someone is delinquent in their task, the original user can actually have the process skip that person’s step and redirect it to someone else or back to them for completion.
- Kenesto lets you attach files to these tasks. Make no mistake, there isn’t some PDM system that tracks versions and iterations. The user can attach a file that comes from anywhere. Furthermore, this file in Kenesto does not automatically update as you change the file on your desktop or your PDM system. It is meant to be reference material that represents the record of the process.
- Kenesto also supports codified processes. If a manager reviews all of the process activities for their organization in a month in Kenesto, they can choose to make the process more formal as a codified template. In this way, it works very much like a workflow engine that executes against a process template. However, there is more flexibility. Certainly steps designated by the manager could still be skipped or rerouted as necessary.
- Kenesto is a cloud system. This means it is available as soon as it is purchased, so there is no long deployment process to execute. And furthermore, the approach of supporting ad-hoc processes first and then codifying them into more rigid template processes allows many to bypass the long and painful effort of reengineering their product development process. Furthermore, because it is in the cloud, others from outside the organization’s four walls can also participate in these processes.
So far, I’ve talked about what Kenesto can do. But so what? What does it mean? Let’s discuss.
Commentary and Analysis
To start, I should start by saying that Kenesto is markedly different from almost all of the software systems that support product development today. Sure, there are some similarities. But the differences enable some new activities that organizations cannot get by using today’s PLM systems. Let me explain a little but more.
As much as we would like to not admit it, the development cycle is full of non-repeatable processes. After a long conversation with an old friend, I published a post titled Where Lean Product Development Goes Wrong. Since that time, I remain convinced that a large part of development needs to be unstructured. Sure, repeatability leads to consistent results. Yet there is a strong need for creativity and innovation in engineering. Today’s PLM systems with rigid process definitions seem ill suited to support that need. And that’s why I feel something like Kenesto with something that looks and feels more like routing to support ad-hoc activities than a workflow enforcing predefined processes seems like a better fit. The great news is that Kenesto can support both.
Another bright spot for Kenesto is it’s similarity to Autodesk’s PLM360. Both are cloud based, so they can be turned on and used instantly. Both are also decoupled from PDM, meaning there is no messy deployment that needs to occur first. These two characteristics translate into finer granularity in the overall IT ecosystem that supports product development. That means organizations can adopt these types of technologies in more of a piecemeal fashion without waiting years for the go-live event. And there is no underestimating the value in that. Organizations are simply sick over long drawn out PLM implementations.
Yet another related topic is adoption. While I was watching the overview of Kenesto, I kept asking myself one question ‘how’s this better than email?’ I see a clear benefit to the organization in theory. Instead of abandoning rigid workflow driven processes, users are more likely to use a system that provides them flexibility to support their own ad-hoc processes. As a result, the organization gains a traceable process record of what happened when, why and how. There’s clearly value in that. But I kept asking myself: ‘why would a user turn to this instead of email?’ There are advantages in being able to redirect a process gone awry as well as visibility into process progress overall. But is that enough to make it ‘sticky’ for them? I’m unsure.
Lastly, as much as being decoupled from PDM provides some advantages, it also provides one concern. I agree that any files attached to tasks in a process should show what was used as part of the process record. But I also think a reference to the latest or generic version of that same file might also be valuable. I would think you would want this sort of process record to be as traversable as possible.
Conclusions and Questions
Kenesto is a cloud based system of supporting and executing both ad-hoc and predefined processes. It seems to provide the need for flexibility in product development processes, especially in the unstructured world of engineering during the design cycle. It is decoupled from PDM, making it a finer granularity system that can be adopted more readily.
Ready for questions? How much of product development’s processes are rigidly structured compared to ad-hoc activities? There seems to be strong movement towards the cloud for enterprise systems in the product development realm. Is on-premise PLM becoming a dinosaur? I’m curious to get your perspective. Weigh in!
Take care. Talk soon. And thanks for reading.
