The digitalization of a social work theory: Experiences of a German child welfare social worker

Background

In 1997, the city of Munich (Germany) restructured its social services by merging five different departments (e.g. youth welfare office, housing office) into three control units – social security, youth and family, and housing and migration – in order to improve planning, coordination, and controlling; at the same time, social services were supposed to be closer to and more easily accessible for the citizens. To achieve the latter goal, social services were merged with child welfare, thereby creating what is called the ‘Regional Social Work (RSW)’. RSW practitioners are responsible for any social problems of all citizens within a certain district, regardless of their age. In order to face the increased challenges, it was intended to professionalize the RSW by taking an acknowledged social work theory as a basis for daily practice. In Germany, social work theories are systems of claims and explanations that are mainly supposed to provide a framework with which social work practitioners can reflect on their actions in daily practice (Engelke et al., 2009). Their development is predominantly rooted in the humanities (cf. Thole, 2012), which might be one reason why social work theories in Germany are usually not directly tailored toward practical applicability (Lorenz, 2012). Thus, implementing social work theories in daily practice is an ongoing endeavor.

The social work theory

The city of Munich decided to implement a model of a social diagnosis (SD), which was henceforth supposed to be a mandatory part of daily RSW practice (Landeshauptstadt München, 2004). This SD is a comparably more practice-oriented approach, which consists of several theoretical models that are subsumed among an overarching framework called the ‘Systemic Paradigm of Social Work’ (SPSW; see Obrecht, 2005a, for a short summary in German). The underlying social work theory of the SD is the theory of Staub-Bernasconi (2018), which is arguably one of the most influential social work theories in German-speaking countries these days. Other theories of the SPSW with a high relevance for the SD are the ‘Theory of Human Needs’ (Obrecht, 2005b), the ‘General Action Theory’ (Obrecht, 1996), and the ‘Outline for Systemic Reasoning’ (Geiser, 2015). The latter two provide generic theoretical guidelines on how to collect and organize information about the systems that are relevant to the social problem(s) at hand and compose the main part of the SD. Furthermore, the SD provides procedural knowledge on how to assess collected information and related problems ethically, conduct predictions, explain problems, and legitimate and choose interventions. Practitioners have been supposed to use the SD for daily practice and documentation since 2004. However, based on my experience from working in an RSW unit for 2 years (2014–2016), during which I had to familiarize myself with a lot of files from older cases, I got the impression that this was rarely the case until 2013. Also, due to the wide scope of responsibility, RSW practice is challenging, and becoming familiar with the SD takes some time. Thus, since 2013, every social worker who becomes employed in RSW starts with a 2-month-long full-time training during which he or she receives full salary. Part of this training is to learn specific theories of the SPSW and to practice the SD.

Incorporation of the theory in an electronic information system

In 2007, an analysis of internal processes revealed that the IT structures for communication and coordination between the RSW and the economic youth welfare service – the unit that is responsible for providing financial resources for interventions and services of the RSW – were no longer sufficient. It was decided to develop a respective electronic information system (EIS; Landeshauptstadt München, 2017). The development of this web-based ‘Software for Economic Youth Welfare and Social Work (SOJA)’ took roughly 8 years. An additional goal of this EIS was to support everyday practice and documentation of the affected units. Respectively, the logic of the SD and its related theories were implemented in the EIS for documentation of practitioners’ daily work. Thus, SOJA was designed to help social workers to collect information, reflect on it, and use it in the sense of the SD within a digital environment (e.g. to improve comparability, legitimate interventions, and improve the overall quality of social services). The software was introduced to practitioners in 2015. All practitioners got 1 week off from work to attend a full-time training course to familiarize themselves with SOJA. In addition, each RSW unit had two social workers who would receive intensified training. They would support practitioners as SOJA knowledge brokers on demand if problems were to occur, once the implementation phase was started. Unfortunately, to my knowledge, there is no report regarding an evaluation of this implementation available yet.

Reactions of practitioners

Once SOJA was put to practice, and despite the intensive training, the city of Munich received quite a bit of backlash from the RSW practitioners, especially regarding three different topics: issues related to technical aspects, software surface and structure, and the underlying social work theory.

First, some problems that were related to technical aspects of SOJA caused discontent among the staff. Practitioners complained about many server downtimes, especially at the beginning of the implementation, leading to a blackout of the software. SOJA is a browser-based application, so any Internet problems affected the workflow of the practitioners as well. In these cases, practitioners had to conduct their documentation with pen and paper, but later they would have to transfer it into the EIS. Furthermore, the structure for accessibility of the system reflected the team-based organization of the staff. Each team member could technically access files from another team member, for instance, to ease fill-in. Similarly, supervisors could access all files from any team member at any time. I had the feeling that especially the general access authorization for supervisors was a potential source of distrust. In addition, data storage has never been clearly communicated. To my knowledge, it has never been clear to practitioners whether the private company that developed SOJA has access to clients’ data or not. A lot of practitioners were skeptical about this, which presumably lowered their appreciation of the new software.

The second issue refers to the structure and the surface of the software. The company that developed SOJA offers respective software development to any child welfare agency in Germany. A basic version of the software is adjusted to the needs of each agency. However, only some of its content can be changed or removed, meaning that some core elements of the software might be visible but generally irrelevant for RSW practice. Practitioners complained about the time-consuming necessity to separate relevant from irrelevant content. Another problem is related to the in-built feedback system of the software. The software provides lists with several headers, each referring to a form. Headers of completed forms are marked in green, while headers referring to empty forms are marked in red. Quite naturally, only some of the available content is usually relevant for a given problem at hand. Supervisors kept telling practitioners that they should only fill in forms referring to relevant content, but practitioners were quite unsatisfied by being left with a lot of red headers in each of their cases. To me, it felt like feedback that tells you that you did not complete your work properly.

The third problem refers to the SD, which served as a theoretical framework for the EIS as well as its implementation within SOJA. I had the feeling that some practitioners were not convinced regarding its benefits. During the first day of a training on the SD, I remember one practitioner who asked why she would have to learn the theory at all. Her main argument was that her daily practice would not differ, regardless of whether she would use the theoretical framework as a guide for her practice or not. Also, SOJA implied the necessity of reflecting on collected information of cases in the way intended by parts of the social work theory and documenting it accordingly. It is reasonable to assume that this might require either the acquisition of new knowledge or (probably more likely due to prior training) the externalization (e.g. for documentation, decision-making processes) of tacit knowledge (Eraut, 2000). Both take a certain amount of effort and time, of course. Thus, practitioners complained that using the software was time-consuming, while at the same time its potential or actual benefits were not clearly communicated.

Conclusion and implications

Digitalization in social work is a rather new phenomenon that is presumably here to stay. For example, the importance of this topic is reflected by the recent dedication of a whole issue of the European Journal of Social Work (Vol. 21, No. 6) to digitalization, and the upcoming Handbook for Social Work and Digitalization (Kutscher et al., 2019). Thus, it is necessary to think about how to improve processes of endeavors that try to promote digitalization in social work, as well as to consider the question of how theoretical frameworks can inform EIS in a way that practitioners can benefit from it in their daily practice. The aim of this article was to contribute to this discussion by providing experiences and respective implications from the implementation of an EIS, that was supposed to go beyond mere documentation by modelling and supporting parts of practitioners’ daily practice. There are as yet no global standards for education regarding digitalization of social work (International Association of Schools of Social Work/International Federation of Social Workers [IASSW/IFSW], 2004). I will also discuss possible implications for social work education. The described experiences focused especially on problems regarding technical issues and software structure and surface, as well as on the underlying theoretical framework. Subsequently, respective implications for practice as well as for research are provided.

First, technical problems that lead to considerable downtimes regarding the usage of an EIS should be avoided, as they might reduce practitioners’ motivation toward the EIS. Furthermore, they increase workload as collected information must be recorded twice. This seems obvious, but respective problems have been reported before (e.g. Gillingham, 2016). In addition, supervisors’ access to practitioners’ records as well as lack of information regarding data storage must be considered as potential sources of distrust (cf. Devlieghere and Roose, 2019). Thus, social work educators should consider including the critical consideration of ethical areas of conflict due to digitalization in their teaching.

Second, as for the structure and the surface of the software, previous reports (e.g. Gillingham, 2016) regarding extensive forms that must be filled in suggest that these might lower practitioners’ motivation toward the EIS. However, as described earlier, this might also be true even if practitioners are free to decide whether forms should be filled in or not. This implies the need to let practitioners personalize the software surface to their needs. Furthermore, the described experiences highlight the importance of a proper in-built feedback structure that marks finished work processes as such. At the same time, work processes that are simply not necessary for a given case should be hidden and not be displayed as work in progress. Offering basic information technology skills (such as working with content management systems) in social work education might enable social workers to understand underlying technical structures of EIS, thereby encouraging them to help shape new and practically valuable EIS.

Third, trying to push an EIS beyond the mere record of clients’ data by implementing theoretical frameworks that model practitioners’ tasks for problem solving seems reasonable. As described earlier, the SD provides procedural knowledge regarding social workers’ workflow, which makes it particularly interesting in serving as an underlying framework for an EIS, since it allows the software to model parts of practitioners’ tasks in a problem-solving process. However, to my knowledge, there is yet no empirical evidence supporting the assumption that the use of the SD is contributing to practitioners’ performance, for example, in generating outcomes that are valued by clients. Hence, underlying frameworks of EIS and their potential benefits for practitioners (and ultimately for clients) should be empirically investigated, even if they might seem reasonable from a theoretical perspective. Respective evidence should be clearly communicated with the staff to justify additional efforts and to increase motivation toward the EIS.