Scripts that go bump in the night

Haven't done a business post in a while.  I keep thinking my work must be interesting, but I'm not sure what to talk about.  Part of it is probably ennui, I've been doing this thing for almost 27 years.  Part of it, maybe that I get to watch while other people have the fun, a lot of my own job has changed to being the mastermind of a business that isn't as small as it used to be.  Eddie takes on new clients and sells first novels, Brady gets to talk to our global partners and sell foreign rights, I get to be their boss.

My current fun task is overseeing an upgrade of our databases.

I don't know if this is something we, like, need-need to do.  The current databases have kept the business running for five years.

But I don't like to settle.  One of the reasons JABberwocky and its clients do well is that we don't let ourselves, try not to let ourselves, get complacent, sit back and be happy with some good news when the right thing to do is ask how that bit of good news can help lead to other and bigger bits.

So as an example, our payment items to clients have increased by 80% from 2008, which is the first year we used the current check database.  It was fine to manually turn $68.49 into "Sixty Eight and 49/100" back then, now I've been thinking lots and lots that there's got to be somebody who knows how to get Filemaker to automate this task for us.  As of today, we have that taken care of.  Though I'm not satisfied entirely, and may call our Filemaker consultant tomorrow to see if the script can take $67 and turn it into "Sixty Seven Dollars and Zero Cents" instead of "Sixty Seven Dollars."

As another example, we have a Global Partners database where we keep the contact info for the foreign agents we work with and foreign publishers we sell to, and which is home base when it comes time to schedule appointments for book fairs.  I've always liked the idea of the database but never been in love with the execution.  I've grown less fond of it as it's had to scale up from handling scheduling just for London Book Fair to handling scheduling for London, Bologna and Frankfurt.  We need better ways to keep track of whom we need to see at each of these Fairs, whom we need to see, whether we are seeing.  And whom we don't need to see, we don't need the editors for children's books that Eddie meets with at Bologna cluttering things for London a few weeks later.  This means more database fields for more Fairs, more layouts in which to view those fields, more scripts to generate more reports so we can keep on top of all of it.

Even though databases can keep lots of information forever and ever and ever, I've often been fond of having a place for historical keeping of information that is different from the place where you keep active information.  Hence, our deals database has a nice table where we can look at the history of paid advances for a book, that is different from the ongoing advances due table where we keep information on anticipated payments.  But, now that the business is growing there are some redundancies here that we can perhaps eliminate if we can find a nice way to view the historical information that will feed off the same information, an attractive portal or something.

With our e-book program, I am around 80% certain that we can do more with the data we're fed from Amazon and Kobo and B&N if we import that data into a database, rather than working with it in spreadsheets.  But can we find ways to automate or simplify how the data is imported?  If we can do that, I'm reasonably certain we can set up scripts that can match this ASIN at Amazon with that ISBN someplace else and put the Simon Green books in the right place and collect and summarize the data.

There are lots and lots of things like that.  Some of them are little, some of them are big.  Some of them (change in how we track advances) will allow us to enter information once that we now enter twice, but others of them might force us to feed the new database fields with new data entering procedures (carefully reviewing our entire global partner editor list to carefully check boxes for each of three different Fairs).  On balance, we hope they will make the business run better.

It was interesting looking for a person to help us with this work.

Person #1 was kind of insulting, looking at everything we'd done and letting us know very clearly that we had major structural flaws with our databases, that we needed to combine everything into one mega-database instead of, as an example, having the checks cut from a different database than was keeping track of the deals themselves.  When he e-mailed the next day to say he wasn't interested in doing all that work, I wasn't that upset.  Yes, the official way to do things is to put all the data for the entire agency into one massive database.  That's generally the way database designers work.  And that's never the way I've wanted it done.  I've wanted it to be robust enough for the business to run smoothly, but simple enough that we could do some basic updating and tweaking of our databases by ourselves.

Person #2, whom we are working with, was much more pleasant.  You have multiple databases, he's not going to go integrating them just because the official way to do things is to do them that way.  He recognizes that things grow of their own accord, not always in the way they would if they were being carefully tended like a bonsai garden, and you work with it.

All of this is going to cost us some money to have help from an outside expert on Filemaker.  That makes me wonder if I should've looked harder in 2008 or looked harder now for some wonderful off-the-shelf software for running a literary agency, are the improvements we're doing now kind of reinventing the wheel of an integrated agency management package?  It's a good question.  I have too much invested in what I've done the past five years to be the best person to answer it.  I still don't like what I see if I go searching the internet for "literary agent software."  It's for Windows, the screen shots look icky, it might be great underneath the hood but you have to pay for the support and the interfaces are invariably clunky looking even if the underpinnings are not. I could go touring offices of my colleagues looking at their programs, I guess, there are probably things out there that aren't advertising on the internet.

But then again, one of the things about the business is that there's an agent for everyone, we don't all run our businesses the exact same way with the exact same focus on things.  I feel extremely comfortable with something I made, that's rooted in something that's worked for a long time.  Our check database, in particular, has its roots back twenty years when we were finally had computers at Scott Meredith.  Not rooted in a bad way, but the basic idea of cutting the checks is that we should all know how much money came in, what got taken out, and what we're paying.

The bigger problem with all of these improvements is the meetings that go along with them.

We have to decide in the office on the best way to do certain things, we have to think on those things, we have to communicate those things to the expert who has to make them work.  We can't save time without first investing it.

And if you're wondering why I haven't done a lot of business posts lately -- well, this stuff has been a lot of the business stuff that's been rolling around in recent weeks and months.  If there's this huge popular outcry to know more, we have more to tell, but I'm not thinking there will be that huge outcry.