Targets and goals-Part 2:Systems and Goals

Recently we had a visitor, who, doing the course of our conversation, mentioned that he is a "systems guy."  Immediately I could relate, for I am also a systems guy.  I  have not usually used that term to describe myself, preferring to use symbology from my previous occupation: map making.

Systems guys are those who use inputs (could be data or resources of some kind) and then work to devise away to achieve a desired output (could be a report, or goal of some kind).

Most of the time we don’t think about the systems guy and they seldom get mentioned.  For example, when I write a newsletter, I use Microsoft Publisher (r) to create the document.  For my supporter database I use software called TNTConnect (r).  The systems people at TNTConnect created a way to link my data to Microsoft Access (r).  The systems people at Microsoft created a way from me to link my Publisher document to Access in order to personalize it and send it to MS Outlook (r) which sends out the e-mail messages.  But I don’t mention that in my newsletter.  The systems people work, often invisibly, behind the scenes to help people be successful.

To design a system, one needs to know the value of and limitations of the inputs.  One also has to be very clear about what the desired output is.

When designing a system, one should also be able to think beyond the stated desires of the customer and plan for other potential uses for the system that could arise.  It may get to the point where the system needs to be tossed and replaced. This is always a hard decision to make, because converting can take a lot of  effort.

When I first started working with NRCS in California, we were using a database program called Prelude that ran on a Unix operating machine.  It was a simple and fairly easy to understand system and I became quite proficient at using it.  But it was also quite limited.  So the powers that be decided to switch to a program called Informix.  Informix is much more powerful and I enjoyed it's capabilities.  But as we moved into the multi-dimensional world of geospatial data servers, it became time to switch, this time to SQL Server. This was a much more complicated than the previous change.  I'm sure I would love the new system, but the switch happened just after I left.

A problem can arise, though, when we get to like our system so much, the system becomes the goal.  I have seen this in government, religion and elsewhere.

We see this situation in government, for example, when an agency is created to address a certain problem.  Later on the problem is solved or the agency isn't needed anymore for some other reason, such as becoming redundant.  But the agency isn't dissolved.  They find some reason to keep it going.  This original goal no longer exists--the mission has become the goal.

We also see this in the realm of religion.  As a systems guy, I like the concept of Systematic Theology.  If God is indeed God then He has to be beyond human understanding.  But we humans want to understand God better so we develop these systematic theologies to help us.  I like that.  The problem comes when we use a system created to help us understand what God is like to instead define what God is like.  Then we end up creating silly ways to look at scripture verses that don't quite seem to fit so they are no longer a problem for us.  Or if God were to do something in the world that does not fit into our carefully crafted boxes we write it off saying, "that's not from God" or "that's from the devil."

We can do the same in ministry.  We might start a program or institution to accomplish a certain goal.  But then we like our program or institution so much, it becomes a goal.  That is not necessarily a problem as long as it remains a secondary goal and the primary goals remain the main goals.  But that doesn't seem to happen.  When the system becomes the goal, as opposed to a means to reach a goal, then usually the primary purpose for it seems to suffer.

Back when I was working for the government, our agency was under pressure to get models written for our soils database that would show how soils would behave in certain situations.  Another agency with a lot more clout than ours was driving this.  The problem was that the model used certain data about soils that wasn't necessarily relevant to all soils.  But we were under orders to put data in those boxes in the database so the model would work.  So, under protest, we did so.  The model worked fine.  However that particular data element is now only meaningful for that model.  We tweaked the data to fit the model rather than fix the model to use the data.  The system (the model) became more important than the original purpose for use of the data.

The reason I am thinking so much about systems these days is that we are encountering situations where the system has become the goal.  For me, as a systems guy, this has been quite frustrating.  But it is a reminder, as we move forward, to, as the adage goes, "keep the main thing the main thing."

So what IS the main thing for us?

I try to keep reminding myself and our Khmu partners of MB Mission's vision and ministry focus.

Our vision: Holistic church planting that transforms communities among the least reached.

Our central ministry focus: multiply healthy disciples and missional leaders.

That is what we're about at MB Mission.  We have all kinds of systems in place to try to accomplish that, but systems are just systems, they are not the goal.

Not that I have already obtained all this, or have already been made perfect, but I press on to take hold of that for which Christ Jesus took hold of me. (Philippians 3:12 NIV)