In order to really understand Social Business Document (SBD) including their characteristics, their requirements in terms of management as well as the different challenges hidden within them, I recommend you to read my PHD thesis (link). The following page should only give you first impressions of what I have been working on.
What are SBD?
The definition of Social Business Documents have already been given on the start-page. But how did I come to call a wiki entry or a blog post a document?
Looking at document theory, documents can for example be defined as any preserves or recorded sign which represents a physical or conceptual phenomenon (Briet, 1951, p. 7). Over time, many different examples of documents have been given. One of the early information scientist who thought about documents was Paul Outlet. He, discussed whether sculptured or museum objects, meaning three-dimensional objects (Otlet, 1914) can be called a document. However, when we generally talk about documents, we mainly think of paper based textual records (Buckland, 1998; Levy, 2001) and today with the widespread of computers also on digital document such word files or PDF documents. (Liu, 2004; Murphy, 2001)
Meanwhile, with the introduction of the internet and web 2.0 technologies, even newer forms of socially-enables collaboration systems such as Facebook or Skype as we know it from social life, or Microsoft SharePoint or IBM Connections in the business world come along with new forms of documents (Zacklad, 2013; Hausmann & Williams, 2015; Hausmann & Williams, 2016). These systems enable the creation of wiki entries, blog posts or forum posts, as examples.
Used within companies, we call these system Enterprise Collaboration System (Schubert & Williams, 2013). The documents created in there, is what I define Social Business Documents. An example showing the different component a Social Business Document can consist of is given on the start-page.
Why looking at SBD in particular?
While in the past the usage of ECS was considered to be in an early stage, they today are being integrated into the day-to-day business of organisations, becoming significant business systems (Moore, 2011; Jones, 2012; Williams et al. 2013b). Consequently the amount of SBD which is created is rising, as well as their importance leading to a need to manage SBD in order to comply with legal requirements, to serve as organisational knowledge or to prevent risks.
However, the characteristics that distinguishes social business documents from traditional documents are that they are collaboratively developed and shared and consist, of more than one single document, but a series of components (Hausmann & Williams, 2015).
While the research on ECS mainly has focused on its adoption and usage and largely leaved out any document management questions, practitioners already face management challenges because of the new characteristics (Williams et al. 2013b).
Within document theory new concepts such as documents for actions are evolving which partly address newer characteristics of documents and the changes we need in document management (Zacklad, 2013; Choksy, 2015). But no deeper insights are given here yet.
Enterprise Information Management and Document Management as the disciplines dealing with unstructured documents, in which SBD can be categorised as well, provide us with many inputs concerning documents. Definitions and concepts around documents and records are given in the literature. We can already find document principles, qualities, challenges and requirements which build the foundation for their management and especially the tools provide us with possible management functions.
However, adapting all these to Social Business Documents lead to several challenges which needs to be addressed as new challenges arise and old concepts can’t be used as they are.
Framework Addressing the Management of SBD
My different findings around the nature and structure of SBD, their document management requirements as well as the challenges have been brought together within an overall framework shown below.
At the top of the framework we have fundamental requirements for document. These requirements thereby have been extracted from the literature and build the basic conditions of what SBD need to comply with. Examples are Accessibility, meaning that documents must be retrievable by those who require them or Traceability requiring that all actions of or to a document are known.
The next layers describe the different kind of Challenges and Actions that have been identified throughout the research. Thereby most challenges have been identified through different Modelling Techniques and Information Models, which are described in the Action layer of the Framework.
In order to understand SBD three different collaboration scenarios have been developed, each representing a different SBD type. These three SBD then have been implemented in 4 different systems, and analysed using 4 different modelling approaches:
- The object modelling was used to understand the technical implementation of SBD leading to their structure. Therefore UML class diagrams were used within the database perspective and Entity-Relationship diagrams within the user view.
- The functional modelling helped in understanding the user-side modification possibilities that can be applied to SBD over their lifetime and resulted in individual functional maps using UML activity diagrams.
- Within the content modelling, the organisational requirements for information about SBD where analysed using a design view and an organisational view especially analysing the metadata of SBD.
- And finally, this three together enabled the lifecycle modelling which identified changes of SBD during their lifecycle and helped in understanding which elements change how.
All these insight enabled the description of SBD characteristics, which parts of can lead to challenges in understanding social business documents as well as in managing them. The extended requirements of SBD build the foundation for addressing the challenges and the fundamental requirements. They suggest, that companies first need to understand their own system capabilities and their own construction of SBD. The information models as well as the different modelling techniques can thereby be used as a starting point.
Second, they need to decide which system they would like to use for the management of SBD meaning the ECS itself, or a DMS for example. Depending on this decision there are processes, guidelines and functions which have to be defined first and than be implemented next.
Looking foreword shows that there is still much to do:
The developed framework for example should be implemented in order to find even more challenges and possible actions.
Furthermore I already looked at the compound SBD as a document and separated between social documents and social content. However, it might also be possible to argue, that depending on its content, a comment could also been seen as a valid document in itself. The implications of this could also be research in the future.
Another thing is the concept of SBD collections. Wiki entries for example are often linked to each other and consist of child and parent pages. So similar as to separate the components as own documents it could also be argued to see the collection as the document.
Furthermore, SBD in this work where analysed in ECS and ECMS. However, today also other enterprise systems such as ERP systems include possibilities for commenting, liking, etc. and therefore are producing SBD. It should be analysed if the same characteristics, challenges and actions apply to them or if they are different again.
And last and what I found from practice most important, it should be analysed what would be the best way to manage SBD. It could be done within the ECS where it is created and edited, or within a DMS where traditional documents are managed.
Note: The sources can be inquired with me by mail.