At metoCube we are focused on knowledge processes, but our process modeling software can also be used to describe industrial processes. The following video shows the Audi A4 production process. As you can see everybody know precisely what to do and how to do it. But.... How did they aquired that knowlege? They probably read some printed procedures and took some training courses (something that can be boosted by having those procedures described in metoCube, with embeded videos showing how to carry out specific actions). And... what happens if a worker identifies a best practice while executing a piece of work? S/He could simply leave a comment on the corresponding metoCube page and the process engineer will receive an alert.
Level: Introductory Interesting article written by S. E Slack (sally@sslack.com), Author and business transformation communications consultant, Freelance writer
Document your processes by creating a template for your process documentation guide that includes the following items: scope statement, applicability matrix, product lines impacted, process roles involved, process management system procedures, exception management process, and decision matrix.
Although it is based on the traditional narrative procedure documentation approach (as oposed to the structured process description approach we have created for metoCube) it can be useful if your procedure documentation project scope is limited. She highlights specially two very important characteristics of procedure documentation: repeteability and standarized format.
We can distinguish between two approaches to capturing an organization's internal knowledge. The first can be referred to as monolothic/document centric. In this approach, the organization generates a collection of documents that are available digitally or are printed into thick reference manuals. These documents are authored with a word processor and consist mainly of text, organized into sections, and typically augmented with charts, diagrams and tables.
The second approach we refer to as structured. In this approach the organization's knowledge is stored in structured form, using a dedicated application. Data is entered into the application using forms that reflect the structure the information will take. For the moment we will consider the exact structure used as a given, implemented by the application.
There are many advantages to a structured approach, but we will only briefly consider two. The first advantage is great flexibility in the presentation of information. Whereas monolithic documents cannot be manipulated, a structured and therefore modular organization of data allows arbitrary composition of information displays, at will. Secondly and more importanly, information that is only implicit (or logically entailed) in the data when entered can be automatically extracted by virtue of its structured nature. In a monolithic scenario, this information is either entirely unavailable, or, if available, it is duplicated, potentially resulting in nightmare problems of incoherence, obsolescence and maintenance.
The two virtues discussed for structured approaches are based on the ability to execute queries against the data, either for the purpose of composing arbitrary on demand displays of information, or to extract entailed information from the data present explicitly. It would seem, therefore, that all we need to develop a structured knowledge application is a database.
If we proceeded in the obvious way from this point, we would attempt to determine an appropriate data model for the domain that the application is storing information about. This excercise is a routine and fundamental step in most any software project, and consists of examining the domain in search of the key entities and relationships that are to be modeled; in short, the practice of conceptual modeling. As well as determining the structure of the information to be stored, one needs to establish which transformations of existing information are most interesting, in other words what queries yield insight and what information compositions are most useful. These interesting queries and information compositions are then implemented by specific program code in the application. After having identified and implemented all required queries and visualisations the application would be complete.
Now, the strategy described above sounds reasonable and is a tried and true development pattern that many database driven applications have followed. Unfortunately, it just does not work for our case of developing an application to manage knowledge. The main reason it does not work is that the process of analyzing a domain in order to establish structure (again, conceptual modeling) never finishes. It does not finish because there is no unique best structure to use, or the discovery of that structure is an ongoing process without end, or because the need to model new domains of knowledge requires a corresponding new structure. The bottom line is a different approach must be used.
The problem can be solved by constructing the application at a higher level of abstraction than that of the data model in the traditional approach. Rather than implement at the level of the metamodel (where specific knowledge plays the role of the model), the application is 'lifted' to a meta-metamodel level, and thus is not coupled to a specific domain structure. The application can then support any structure that can be expressed in terms of the meta-metamodel chosen. This is the theory. Lifting the application can be done in many ways, and has important consequences besides the aim of solving the problems of the traditional approach.
Firstly, the data model itself must be lifted to the level of meta-metamodel. Without going into the details, an abstraction that can be used is that of a graph (specifically, labeled multidigraph), as defined in mathematics. It may help to think of nodes and links of a graph as entities and relationships (ER modeling), or classes and relationships (OO modeling). Details aside, it turns out that the graph abstraction, with appropriate semantics, is powerful enough to support the modeling of almost any domain of knowledge. Thus the lifted data, instead of speaking natively of instances of classes of things and their properties, will speak natively of classes and relationships themselves, allowing it to capture domain knowledge in a context of ongoing conceptual modeling.
But lifting the application is not just lifting the data model. Although this first step insulates the application from fundamental changes to the data model, it does not insulate it completely as the application is more than its data model. If the process of lifting stopped now, it would still be up to the application implementers to write new code against the abstract data model, as new visualisations, and significant knowledge perspectives and structures were discovered, even if the data model itself remained unchanged throughout. So, even if the fundamental problem were solved, code changes would still be required. This problem is compouned by the fact that in knowledge applications the people with domain specific knowledge and knowledge engineering skills who further conceptual design and discover new visualisations are rarely the same people with the technical skills necessary to implement the associated changes in code. Furthermore, on the specific subject of adding new insightful knowledge transformations and visualisations, it happens that writing the necessary queries is much harder against an abstract data model than it would be using a traditional approach. Writing the "abstract equivalent" of a normal SQL query to extract a given piece of information is more complex. Hence, solving the central technical problem of the traditional approach reveals other problems that must also be solved. This is what lifting the rest of the application is about.
In essence, the central theme of a lifted knowledge application is that of "pushing" responsibilities and tasks that traditionally are carried out by application developers into the hands of application users, knowledge engineers. This objective attempts to solve two problems, discussed above. First, it would allow the application code to be insulated from the ongoing process of conceptual design and related refinements. Second, it would grant those people with domain specific knowlege and skills the ability to materialise their discoveries and insights, without requiring programming or other technical skills. These features, together with an abstract model capable of capturing knowledge from diverse domains, forms the core of a viable application that follows the structured approach to capturing an organization's knowledge, as outlined at the very beginning of this discussion.
At its very basic, the application elements that must be lifted to conform to the abstraction level of the meta-metamodel are: data storage and manipulation, and data extraction, transformation and visualisation. We will consider each of these two aspects in turn.
If the application user, in this case a knowledge engineer, is to define a domain specific data model, he/she will presumably also design forms for creating and editing the data that conform to that data model. The application must therefore allow the generic creation of forms for the creation, storage and editing of data that write to the application's abstract data model. Such form design mechanisms should include user interface elements for specifying relationships as well as the usual range of scalar types, such as numbers, dates etc. Specific forms are thus defined for each of the types the knowledge engineer identifies; model elements of that type are manipulated through its associated forms. We will not delve further into the details of generic type-based form design and generation, but a successful and usable implementation is essential for the objective of pushing responsibilities into the role of the knowledge engineer/domain expert.
Just as a user defined data model implies user defined data manipulation interfaces, as we saw above, so too does it requires user defined data extraction, perspectives, and visualisations in order to obtain information that is significant, in the sense of meaningful and insightful. In a traditional setting, the excercise of conceptual modeling goes hand in hand with the analysis that yields what set of queries and visualisations are interesting for the domain at hand. Defining a perspective or view on data is a matter of defining what subset of data to show (query), and how to show it (display code). In our case, these queries and visualisations must defined by the user in a manner that does not require technical skills necessary with typical extraction (SQL) and information presentation (display code) methods. As was noted a few paragraphs back, querying an abstract data model with SQL is even harder than querying a "normal" data model. It is necessary therefore to develop a query language that is specifically designed to target a graph as its data model, with special mechanisms for easy graph traversal and other graph operations that are the abstract equivalent of selecting data. Additionally, flexible mechanisms must exist to define and customize how queried data is to be presented. A pluggable rendering architecture can provide various customizable visualisations, such as trees, lists, tables etc. For maximum flexibility, a graph aware template language (HTML for web applications) can be developed to allow the user to create any information display possible within the medium. A powerful yet simple graph oriented query language, a flexible rendering architecture with builtin renderers and an expressive template language work together harmoniously to allow the creation of arbitrary views, as conceived by the knowledge engineer.
Having lifted all of the core elements of the application, the structured approach to knowledge management becomes practical, and the benefits of said approach can be reaped. The key to the finished technology's degree of success is how far its users, with limited technical skills, manage to leverage its generic storage, extraction and display mechanisms operating on the abstract data model to achieve their objectives in capturing and presenting knowledge. Innovations in query languages, template languages, including user friendly tool assists, and in agile data entry and manipulation user interfaces can push the native power of the application into the user's hands.
Engineering
While engineering considerations have not been made, it is importante to realise that a fundamentally different technical solution has correspondingly fundamental consequences, and without proper engineering the implementation can collapse, however attractive and elegant the theory can be. In particular, lifting the data model to the level of meta-metamodel comes with a significant performance price, as queries become more complex and much harder to optimize. Another example can be found in powerful data visualisation mechanisms, that allow great flexibility but at the same time can create performance problems if abused. The message is simply that engineering (including but not limited to performance considerations), cannot be neglected, even if it was not the main subject of this discussion.
Constructing other information systems
An application that can be customised to generically store, edit, query and present arbitrary data is close to offering the user power comparable to that of programming in a traditional application. In other words, storing, querying and presenting data is the backbone of any information system, so presumably other information systems can be constructed on top of the generic facilities of the application to serve other needs. We will not go into more detail here, except to say that it seems there is a large potential for development. Some relevant and actually implemented examples of this are messaging systems, alert and notification systems, and data-centric (or object-centric) workflow systems. These examples are especially relevant in an application that manages an organization's knowledege.
What about the semantic web?
I have deliberately refrained from mentioning the Semantic Web initiative in order to develop a practical, bottom up understanding of the problems that require solutions before mentioning the solutions themselves. Semantic Web technologies offer solutions that have a direct bearing on the problems described in a traditional database approach to capturing knowledge. For example, RDF, RDFS, SPARQL and OWL technologies directly address the problem of capturing knowledge about diverse domains (knowledge representation) by providing a robust abstract data model with powerful transformation (inferencing) capabilities.
Este artículo propone una forma de diseñar las operaciones de una start-up para que estén claros sus objetivos y cual es la forma de llegar hasta ellos. No es ni mucho menos el único método que existe ni el más adecuado en todas las situaciones, pero si es un método sencillo con un enfoque práctico para ayudar a un emprendedor a lograr que el trabajo en su empresa esté alineado con objetivos de la misma.
Una start-up es un proyecto empresarial que un emprendedor está poniendo en marcha. Esto quiere decir que para diseñar sus operaciones no se tiene como referencia aquello se hace en la actualidad, ya que todo se está haciendo por primera vez. Es una situación similar a la de un pintor que decide pintar un cuadro y empieza haciendo un boceto.
Diseñar las operaciones de una start-up consiste en definir cuales son sus objetivos y los indicadores a través de los cuales se van a medir, definir cómo se va a estructurar la organización en departamentos, grupos y puestos de trabajo, definir los procesos que se van a llevar a cabo y los proyectos que habrá que acometer, y definir las herramientas que nos van a ayudar en nuestro trabajo. Si el emprendedor ha realizado un plan de negocio, gran parte de esta información debería estar ya madurada como fruto de las reflexiones a las que obliga su elaboración. Es recomendable plasmar toda esta información en un manual de operaciones y ponerlo a disposición de todas las personas que deban o deseen conocerlo, como trabajadores, partners, socios, etc... Puede ser una buena idea crear guías para cada uno de estos perfiles que les indiquen las partes del manual que son especialmente relevantes para ellos. El objetivo último de este manual de operaciones es conseguir que todos ellos comprendan hacia dónde se dirige la empresa y cómo se quiere llegar allí, de forma que todos rememos de forma coordinada en la misma dirección para conseguirlo.
Sin duda la información más importante, y la que tienen que tener presente en todo momento los trabajadores, son los objetivos de la empresa. Para definirlos, elabora un árbol en el que la misión de la organización esté en el nivel más alto, y ve desagregándolo en objetivos cada vez más tangibles y accionables. Para medir la consecución de algunos de estos objetivos define los indicadores necesarios y los valores que deseas que éstos tengan en el futuro.
A continuación define los distintos departamentos, grupos y puestos de trabajo que van a existir en tu empresa. Defínelos como una árbol en el que los departamentos se componen desubdepartamentos y grupos y en estos se ubican los distintos puestos de trabajo.
Lo siguiente es identificar y definir los procesos que se van a llevar a cabo para conseguir esos objetivos. Como punto de partida puedes tomar la cadena de valor dePorter (o cualquier otro marco de clasificación de procesos) e ir desagregando cada proceso en subprocesos hasta llegar a tareas que vaya a llevar a cabo una persona o grupo. Describe las tareas hasta el punto en el queálguien con los conocimientos y habilidades necesarias pueda llevarla a cabo sin tener que preguntar nada. No dudes en utilizar imágenes y vídeos que ayuden a entender cómo llevarlas a cabo. Para cada tarea identifica como mínimoinputs, outputs, puesto de trabajo responsable y herramientas utilizadas. Entre los outputs estarán los productos y servicios que vas a fabricar o proveer. Asegúrate de describir con precisión sus especificaciones y sus principales funcionalidades. Deberás identificar también los proyectos que vayas a acometer, aunque no es necesario que los describas en detalle (eso es mejor hacerlo en alguna herramienta de gestión de proyectos). Juntando los procesos y los proyectos tendrás una imagen completa del trabajo que se va a llevar a cabo en tu empresa.
Por último, identifica las herramientas (informáticas o no) que vayas a utilizar, y escribe o referencia las guías que expliquen cómo llevar a cabo las acciones más frecuentes (por ejemplo, "Crear una factura en el sistema de facturación"). Si mantienes esta información así, y la referencias desde losprocedimientos, es mucho más fácil de gestionar, reutilizar y actualizar.
Como habrás visto, gran parte del trabajo consiste en definir estructuras en forma de árbol. La forma más práctica y flexible de hacerlo es "dibujar" el árbol sobre una superficie en la que vas pegando post-its con el nombre del elemento correspondiente. Una vez tengas claro el árbol puedes documentarlo.
Intenta repetir información lo menos posible. Así te será más fácil mantener la coherencia en el manual cuando introduzcas cambios. Esextremadamente importante que mantengas la consistencia en los nombres de los elementos a lo largo del manual. No puedes llamar a un puesto "Agente de Help Desk" en la descripción del puesto de trabajo y en un procedimiento referirte a él como "Técnico de soporte".
La creación de este manual de operaciones es un proceso iterativo que no termina nunca. Lo más recomendable es comenzar definiendo laestructrura básica del manual de operaciones, algo como su índice o su "esqueleto", sin preocuparse de los detalles. Una vez está más o menos claro esto, se puede ir describiendo cada elemento. También se deberá decidir qué partes se deben definir, hasta qué punto y en qué momento. No tiene demasiado sentido tener definidos hasta el más mínimo detalle los procesos de cobro al principio del ciclo de vida de unastart-up que va a estar dos años desarrollando el producto. Otra buena idea es elaborar el manual de usuario desde el principio siendo consciente de que va a ser algo vivo que va a irevolucionando, al igual que tu start-up.
Una start-up tiene el ambicioso objetivo de cambiar el mundo. El primer paso para conseguirlo es asegurarse de que todos los que toman parte en ella saben qué deben hacer, por qué deben hacerlo y cómo deben hacerlo.
Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks
Until recently all frameworks and tools that could be used to create an Enterprise Architecture were very complicated, included lots of artifacts and its implantation usually meant years of hard work... metoCube was something different. Its proposition was very simple: if you want to describe your organization and its operations use our tool instead of MS word and you will enjoy the benefits of the Structured Operations Description approach...
But recently things have started to change. Lighter EA frameworks and tools have been developed (see EA lite, archimate, etc...) They are still more rigurous and wider in scope compared to the more agile Structured Operations Description approach, but it will be interesting to see how they evolve.
The following article describes this new EA trend:
Since I began writing procedures about 10 years ago, I noticed that all of them had in someway similar underlying structures. At the most basic level, all of them stated that someone was responsible of working to transform an input into an output. After an enourmous ammounts of time spent in analyzing different procedures, Business Process Management tools, Enterprise Architecture standards, modeling frameworks, etc... we came up with a framework that allows process engineers to describe processes (in fact the scope is wider, including people and technology) applying process documentation best practices and with no additional effort:
SOMoF (Simple Operations Modeling Framework) is a set of procedure documentation techniques and tools that allows organizations (enterprises, divisions, departments, etc...) to describe their operations in a simple way using a set of interrelated elements (such as processes, tasks, roles, etc...). Procedures documented using SOMoF have a uniform structure and format that makes it easier to consult and understand by workers.
Durante estos días estoy terminando de modelar los procesos que hay que seguir para organizar un Iniciador en tu ciudad. Cuando estén dados los últimos retoques lo publicaremos oficialmente.
Hemos tratado de concentrar todas las lecciones aprendidas y mejores prácticas identificadas en una serie de procedimientos que faciliten a los promotores locales la formación del equipo local, la organización del primer evento y la continuidad de los mismos. Como verás es bastante fácil y sólo hacen falta ganas.
PRINCE2 has a process-based approach to Project Management. The processes define the management activities to be carried out during the project (PRINCE2 also describes a number of components that are applied within the appropriate activities. These component will remain out of scope of this piece of work).
The PRINCE2 process model, part of which is shown in the diagram above, consists of eight management processes, covering all activities from starting the project off on the right note, right through to controlling and managing the project's progress, to final completion. The common PL PLANNING process is used by the four other processes.
In reality real world projects) each process should be tempered with the question "How extensively should this process be applied to this particular project?"
This model was created by Paul Michael, a Consultant with over 10 years experience documenting Financial Workflow and Managing software implementations within the Financial Services Industry. To provide feedback on the models created, or for assistance in developing these models further, please contact me on paulchas1@hotmail.com or through my evolving blog paulmichael.wordpress.com.
Paul Michaels has created this process describing a general STP workflow model for a Buy Side Institution:
This model describes a general STP workflow model for a Buy Side Institution (Fund Manager, Mutual Fund, Private Wealth Manager). For purposes of simplicity it is described for a Buy transaction only.
It is a generic model, and not representative of how all Buy Side firms operate, but should give a general overview. It is based, loosely on an equity transaction, but of course would vary to a degree depending on instrument type, market, etc.
For further information on this model, and how to implement this model in your organisation (including system selection) please contact paulchas1@hotmail.com
The University of Santa Cruz has published this document describing some best practices in process documentation:
Preparing a policy or procedure document for UC Santa Cruz’ InfoSlug on-line policy and procedure system is not as mysterious or difficult as you might think. This guide is designed to explain the campus’ policy and procedure framework, to help policy and procedure owners organize their written documentation, and to act as a resource as they navigate the approval process. You will find the information in this “how to” guide helpful if you are responsible for formulating or documenting new or existing policies and procedures.
Remember "Managing knowledge processes"? It was "The blog for anyone interested in methodology and process management in knowledge intensive organizations". I began writing it in March 2005 but discontinued it some time ago... but we are back on the run!!!
Lots of things have happened since then. We launched the first version of metoCube, had our first sales, developed the second version ... During this time the focus of metoCube has changed from pure procedure documentation to operations modeling. That's what we are going to talk about in this blog: modeling business processes, describing job positions, writing user manuals... anything that allows you to better understand how to describe your organization's operations effectively...The blog will now be called "Describing operations ".
