<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener("load", function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <iframe src="http://www.blogger.com/navbar.g?targetBlogID=3207116622901103255&amp;blogName=crewNeckTech&amp;publishMode=PUBLISH_MODE_SFTP&amp;navbarType=BLACK&amp;layoutType=CLASSIC&amp;homepageUrl=http%3A%2F%2Fwww.crewnecktech.com%2F&amp;searchRoot=http%3A%2F%2Fblogsearch.google.com%2F" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" height="30px" width="100%" id="navbar-iframe" title="Blogger Navigation and Search"></iframe> <div></div>

About

"I am Jon Pierce, the crewNeckTech. I am employed full-time at Crossroads Community Church as the Technology Specialist. Fulfilling this title pretty much makes me in charge of anything with current flowing through it... This ranges from our 1 electronic stapler, to our 6 servers, to our 8 Rooftop HVAC units, and to our 64 input video switcher."

    Archives

    Continuing the CCB world takeov... errr.. implementation Saturday, September 6, 2008 |

    So, I'm a little behind on here, but last week we "completed" our database migration from Shelby to Church Community Builder. This basically involved:
    1. getting the data out of Shelby (by the way thanks Pam, who ended up keying in the child-work approved fields for me, and to Ron who got our member list 100% up to date prior to sending the final data!)
    2. checking the data in the newly created spreadsheet
    3. getting the data into CCB
    4. checking the data in CCB
    5. Susie fixing the data I sent wrong in CCB
    6. Susie fixing the data I didn't understand in CCB
    7. and Susie fixing the data I sent wrong in CCB
    Susie Fowler, our data import guru over at Church Community Builder, has really been a blessing as of late!

    Basically 2 things went "wrong" in getting data pushed to CCB:
    1. I didn't find some of the wrong items in the spreadsheet prior to sending
    2. I didn't fully understand the way new records would be imported into CCB en masse
    As to the wrong items, this really is a testament to why you should never, never use a spreadsheet to track your church's people information... Not that this is a good plan, but everything is laid out so nice in CCB that once your data is in the program, it is easy to find the things that are wrong. Don't get me wrong, I checked, fixed, rechecked, fixed, and rechecked those msSQL statements and final data output in the spreadsheet... but I missed a few, but they were really easy to see in CCB! In fact, so easy that within 5 minutes of assigning the exec pastor a login, he saw something I missed that was wrong. "Oh Susie....."

    As to the things I didn't understand, a question is worth the values in 5,175 individual people records... I thought that by setting the defaults for privacy for "new records" on the admin side of CCB would apply to all new records imported into the database as well. In fact, I thought it so hard, I was sure I read it somewhere or took notes on it from a conversation somewhere... Turns out I didn't, I just thought it, saw the "defaults for new records" on the privacy settings page, set those, and went about my business. In fact, the truth of the matter is almost 100% reverse, there is a FAQ in their data import guidelines that explicitly says what they will default those settings to. But for the "almost", it also says in the same document that you can setup your "privacy defaults" in the database prior to conversion, and then the Privacy Defaults page says that it will be applied to all new profiles. I think they win though. We needed 5,175 records changed, but we've already added new individuals and put in new contributions, i.e. this is already a living database. A quick call to Susie, a little discussion, and she'll have them all set and ready to go middle of next week after she writes code to handle it for us!

    So a couple of weeks after the import process got started, here we are really, really close to having everything ready to go in CCB. It's quite exciting, and even more exciting as I see people starting use the data, and starting to get some training.

    Labels: ,

    MS SQL calls Wednesday, August 20, 2008 |

    Well, We're progressing in our CCB implementation.. On my team I've got Susie Fowler: data migration specialist, Carol Darling: implementation specialist, and of course still my awesome sales guy, Steve Caton... atwixt the three, I'd guess I've spent an average of 2 hours in communications back and forth per day over the course of the past week. Believe it or not, it's great fun for me to discuss implementation priorities, scheduling, data migration and future data strategy.

    Calling to attention data migration, I'm currently knee-deep in MS SQL statements in an attempt to pull out data from our current Shelby database and into a generic spreadsheet. For the most part all of these statements were setup for me and e-mailed to me from Susie Fowler. However, as I'm sure is always the case, we've got a couple of exceptions to the 'norm'. We stored item x, y, and z in section a instead of b. Also, we appear to be on a different version of Shelby than those calls were written for... Which pretty much means that I have to find and remap where those items are stored. So I get to figure out how to make b turn into a.

    I've gotten it mostly figured out at this point, however, I need to start weighing some time factors. For example, I know that we track "child-work-approved" status in our database currently by belonging to certain organizations in our org tree in shelby. I know that there are about 8 different organizations that indicate that approval. I also know that those organizations are based on 2 different organizational levels within shelby and therefore reside in two different relational tables to two different id tables for those level structures. On the other hand, I have a paper report sitting beside my desk that was run from Pam Ervin, Family Ministries Assistant. I know that this report is only about 300 names long... So is it quicker to find, modify, and check 300 cells in a spreadsheet or code the above conditions into a SQL statement to modify those cells for me?

    Probably, based on my knowledge level of the Shelby database structure and how I constantly try to code mySQL style in the MS SQL query box, it will be quicker to just modify the cells. The geek in me wants to take the time to figure it out... but there's just too much going on to justify the "pretty" solution.

    I'd love to say I spent the last 15 minutes writing this post prior to actually making the decision... but I didn't... I've probably blown 2 hours finding relevant Shelby tables and mapping appropriate SQL statements to pull it all together, but I feel like it's going to be another 4 or so till I get it just right... I know I can find, key in, check, and recheck 300 cells in less than 4 hours, so that's where I'm heading!

    Labels: ,

    Decisions, decisions... Thursday, August 14, 2008 |

    I've spent some good chunks of the last several months researching church management systems. We were more or less 100% split, in my opinion, atwixt the 2 best church management systems out there: Church Community Builder (v 2.0), and Fellowship One.

    I frankly feel as if I've got to be the most educated person on the planet (approximately for the next two weeks, as each system just keeps evolving...) on the good, the bad, and the beautiful of each of these two systems. They both have strengths and weaknesses...

    They both take what we have now, and make it sooo much better. They both provide an excellent/accessible user interface that just plain doesn't exist in other packages with similar feature sets. They both come with a long list of features (CCB's list and F1's list). To summarize, they both manage people, groups, finances, check-in, web-related API stuff really well.

    They're both extremely secure, well-protected, and well-backed up. They both have an excellent track record of little to no service outages.

    I've had excellent, productive, thought-provoking discussions with both of my primary "sales" contacts at each company. In fact, we've both got each others' cell numbers just to keep conversations going outside the office... Dedication... They both have an incredible passion to see their product revolutionize our church.

    But there are some differences. So much information on the differences in their feature sets was floating around in my head, that I just had to get it down on (virtual) paper and analyze it without anything else popping up. What follows is a dump of my brain on those ups and downs (bold is really good stuff):


    I could stay in research mode forever, literally.. There is so much to each system, it has taken a long time to understand the benefits of one vs. another. And once you go with one, there is great value (both in implementation costs and longevity of data) in sticking with that choice for a long time. But I had to stop researching/talking, and start doing. With some excellent help from my dad (the executive pastor) we finally did make a decision. We ended up going with CCB pretty much because we ranked the online community the top priority amongst the differences, and the calendaring/resource management second. 2 big items currently in CCB's favor.

    I can see that list above having gone either way depending on priorities, but for our church, CCB was the answer. I am really excited about partnering with Church Community Builder, and can't wait to start implementation! I hope our ministries get to work together for quite a long time. Fellowship, I know many great churches using your system, and I have no doubt many more will flock your direction as well!

    *8/15/08 1:16 AM Update* I will try to make changes to the above spreadsheet as more details & features are made aware to me... already the sheet has changed!

    Labels: , ,

    Shelby "Contributions Inquiry" Wednesday, August 6, 2008 |

    Wow, Found a real problem today. I was poking around Shelby EZ-View trying to find a nice easy way to export a vCard or something to jump into my Outlook contacts. So I was right-clicking here and there, and what did I find? Something called "Contributions Inquiry." Hmm... I thought, that's odd, I don't have rights to contributions. (I should know, I set the rights...) So looked up myself, and went for it. Bam! There it was, my contributions history. I dash into Shelby and log in as the system supervisor, check my "security group", and sure enough no rights at all to anything in the contributions module. Wanting to rectify this immediately, I give Shelby a call, and they quickly let me know about an option under membership and prospects entitled, "Contributions Inquiry"... So I zap those Inquiry rights from those two modules from that "group" and lo and behold the option for the inquiry is removed from my EZ-View.

    I hate to think how easily that could've turned into a big mess, but I am left with these 3 thoughts.
    1. I need to read more documentation.
    2. I need to try and "break" into the system more.
    3. Why would Shelby put contributions permission stuff in the other modules security sections? OR if it makes sense to them, maybe a link to it from the contributions module's security sections?
    Please note that these are in order, I have no doubt that if I was more careful in my setup I would've caught it before it had the ability to become an issue.

    By the way, the reference to security groups is really a little, fun poke because security groups don't exist, but there is an option called, "Set security equal to", and that's what I use for my "security groups." I create an "individual" with the name group combined with a name for the group, and set permissions for that "group" on those security settings. Then on actual individuals, I set their security permissions equal to that "group." Not beautiful, but it's certainly a lot easier to manage than 30 users permissions individually.

    Labels: , ,