Pure obstacle avoidance algorithms in situations like this will create incredibly odd-looking behavior. For example, the creature will look like it's drunk when it's wiggling around some static obstacle in the middle of the way. Or it might take a very long route to get around some obstacles when going around the other way would've taken the enemy a tenth of the time to get to you.
It can also introduce some bugs. For example, if you mark your blocking tiles as obstacles and let the enemies steer away from them based on both distance to the obstacle and distance to you (both in terms of magnitude as well as direction), you might get a situation like this, where the algorithm will make the enemy walk away from the player instead of towards him or where the creature simply may get stuck:
Or your enemy looks like a dumbass:
(or like a cheater if it simply pushes through the small passage :P)
These are pretty dumb examples since it assumes that your avoidance algorithm is very simple (and stupid), but these kinds of scenarios occur sometimes, no matter what kind of algorithm for steering or avoidance you use.
The reason for this is that the enemy has no "whole path"-information, which means that while its current decision based upon the currently relevant obstacle may be correct, it may push him into a state towards the next obstacle where this kind of equilibrium or false decision behavior occurs.
There are probably weird things that you can incorporate into your avoidance algorithm which minimizes these scenarios or makes them go away completely, but I can't help but think that this is ugly.
Instead, just use a regular path finding algorithm like A* to search a path towards your character. Especially in tile-based games, where the cost between nodes (your tiles) usually stays constant, that kind of algorithm is an easy choice.
A* is usually pretty costly if you want to recalculate the path at every frame, but as long as it stays simple (just a couple of enemies) this shouldn't be a problem at all (processors are fast).
You can also opt to only update the path every couple of frames or so since the player won't notice it if the path was calculated once or twice in those 60 frames during the last second.
By the way, if you look for some good explanation for the A* algorithm, I can really recommend the chapter on it in Game Programming Gems 1 (3.3 to 3.5). The book may be hard (or expensive) to come by (it's been a while, but when I searched for it a while ago it was pretty expensive if you wanted to buy it new), but it's worth the money.